Joe, Bryan, In an early draft of the Core Component spec both extension and restriction (from CC to BIE) were allowed. The CC team discussed this and concluded it to be undesirable. One could remove all properties of an ACC and replace them by entirely different ones, loosing all relationship between the BIE's that were based on the same CC (and effectively loosing CC-BIE relationship). Note that the "based on" relationship between CC's and BIE's is not in the first place meant for technical XML schema production, but to enable semantic interoperability between systems that endorse the standard. The team assessed two alternatives: derivation by extension and derivation by restriction. Derivation by extension (the UML "Specialization" association) would: 1. Lead to empty CC's, the overlap between BIE's in the various very diverse contexts is too little to find properties that are common to all 2. Would scatter the BIE-definitions and structures over all specific context-specific implementations, making it impossible to find similarities that would allow communication between those implementations. Harmonisation (why the CC-effort was started in the first place) would be practically impossible. So the team decided to choose the other option: derivation by restriction. This enforces implementors to submit new BIE's as CC's at a higher level of abstraction so they can be reused in other contexts. So implementation is not a one-way street. Feed back from implementors to be used by other implementors is built in in the spec! Note that BIE properties are not copied to the CC level as such. They are generalized for that purpose. E.g. a BBIE called EANUCC_ Item. Identifier becomes a more generic Item. Identifier at BCC level. Note also that document assembly is outside the scope of CCTS, so we are not combining all parts of "orders" and "despatch advices" of all industries in a super-order or super despatch advice. Derivation by restriction is imho even easier to implement than derivation by extension. Restriction is defined as a restriction on semantical definition and restriction on the structure (properties, attributes, facets). A constraint rule (in OCL, Business Rule Language, first order logic or any XML based implementation of that) in combination with the CC gives you the BIE. Extension would be more complex: you need new definitions and new structures, which needs creativity. The main problem is that object oriented people were not brought up this way. Fred -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: woensdag 28 juli 2004 15:10 To: Bryan Rasmussen Cc: ebxml-dev@lists.ebxml.org Subject: Re: [ebxml-dev] ebXML core components derivation by restriction Bryan, Commenting solely on the Core Components Technical Specification, not on UBL's implementation: According to my highly detailed analysis of the CCTS (current version and several versions past) has - in my opinion - shown that the Core Components methodology, as documented in the CCTS, has not given adequate consideration to the notions of inheritance and extension. I have communicated this to the UN/CEFACT CCTS team in the past. Kind Regards, Joe Chiusano Booz Allen Hamilton Strategy and Technology Consultants to the World Bryan Rasmussen wrote: > > Hi, > > The core components work basically via derivation by restriction, I've > noticed a little grousing about that here and there, will future > usages of core components allow derivation via other methodologies? > > It seems to me that this has affected the derivation methodologies of > UBL > reference: http://www.oasis-open.org/archives/ubl-cmsc/200401/msg00001.html, > where it looks to me that what one has to do if one wants to add elements is > first off derive by restriction, quoting from the referenced url "first > derive by restriction, eliminating the element referring to ubl:PartyType > from the myns:MyOrderType, then derive by extension adding an element that > refers to myns:MyPartyType. > " -- Kind Regards, Joseph Chiusano Associate Booz Allen Hamilton
<<attachment: winmail.dat>>