OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl-lcsc] Is Local/Global a Type-reuse issue?


On Tue, 24 Jun 2003, G. Ken Holman wrote:

>>At 2003-06-24 23:52 +0800, Chin Chee Kai wrote:
>>>This isn't so much of a global/local issue than a type-reuse issue.
>>
>>Ahhhh ... my confusion then ... I thought the global/local issues *was
>>entirely* a type-reuse issue.

Global/local discussion in the XML Schema context is about how
the elements and types (mostly subtypes) are declared.  In a 
schema design project like this, there could be intimate connection
between type-reuse and global/local, but there need not be any either.
For instance, 0.70 schemas were heavily global on elements and types,
but with little reuse of types.  If one takes the time, one could
come out with heavily locally-oriented schemas based on the same
spreadsheet models and end up with little reuse of types again.



>>>The type-reuse mechanism (what you described as "single type
>>>for all parties") was carried over from the 0.80 spreadsheets'
>>>model change to reuse more types that are literally exact
>>>copies with different names when they were in 0.70 (as you
>>>pointed out).  I think there was no position change from
>>>the London meeting on encouraging type-reuse.
>>
>>Ummmmm ... then I apologize for being so very confused.  Because if I look
>>at the XPath addresses in 0.70, I see the following:
>>
>>   /po:Order/cat:BuyerParty/cat:ID
>>   /po:Order/cat:BuyerParty/cat:PartyName/cat:Name
>>   /po:Order/cat:BuyerParty/cat:Address/cat:ID
>>
>>After the London meeting I was anticipating seeing:
>>
>>   /po:Order/cat:BuyerParty/cat:ID
>>   /po:Order/cat:BuyerParty/cat:BuyerPartyPartyName/cat:BuyerPartyName
>>   /po:Order/cat:BuyerParty/cat:BuyerPartyAddress/cat:ID

For the latter, I'm not sure how to interpret in a systematic
manner.  If it's prepending parent's element name to each of
child element's name, the "cat:ID" ought to be very long
("cat:BuyerPartyID" and "cat:BuyerPartyAddressID" respectively),
and wouldn't be depth-wise scalable.  




>>Type reuse of cat:Address would not allow the element members of that type
>>to have different labels under different parent elements.

That seems like a direct consequence of type-reuse.  The parent
element of an instance of cat:Address can be named differently,
and is sufficient to distinguish between two instance child elements 
of cat:Address with exactly same element member names within.


>>Don't get me wrong ... I *want* what I had in 0.70 where all of the address
>>components of all of the parties had the same labels because they were of
>>the same type:  Address.

See below as well.



>>What I thought was happening with the global/local discussion is that
>>type-based programmer approaches to database-oriented applications needed
>>individual types such as BuyerPartyAddress because the BuyerParty type was
>>necessarily different than the SellerParty type, thus producing different
>>element labels used in the types, thus producing different element labels
>>under each kind of party in the instance.

Incidentally, BuyerPartyType is different from SellerPartyType for
very different reasons in 0.70 and 0.80 schemas.  In 0.70 schemas,
BuyerPartyType and SellerPartyType had the same content elements,
but was labeled as different types at the model level (ie. no reuse,
or forgot to reuse).  The schemas thus ended up with 2 different 
types but of the same content elements.  In 0.80 schemas, BuyerPartyType
has been removed from Reusable, as all occurrences of BuyerParty 
elements will reuse the AddressType.  SellerPartyType, however, remains
recognised as a distinctly different type at the modelling level.  
So SellerPartyType remains in Reusable schema.


Looking at your Order example, in 0.70's, you would do:

>>   /po:Order/cat:BuyerParty/cat:ID
>>   /po:Order/cat:BuyerParty/cat:PartyName/cat:Name
>>   /po:Order/cat:BuyerParty/cat:Address/cat:ID

But in 0.80's, your paths would probably have to look like:

     /po:Order/po:BuyerParty/cat:ID
     /po:Order/po:BuyerParty/cat:PartyName/cat:Name
     /po:Order/po:BuyerParty/cat:Address/cat:ID

because BuyerParty element is now defined only in Order reusing 
the type AddressType.




>>Can I, then, rely on what I see in 0.80 Draft 3 that type-reuse, which ends
>>up becoming label-reuse because the type described the labels for my
>>element types, is going to be in the final 0.80?  I would be relieved to
>>hear so.

Type-reuse has been a stated guideline.  0.70 probably didn't 
live up to it for one reason or another.  We hope 0.80 does.



Hope this helps.


Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]