[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]