More comments below (sorry for the 2-part reply) "Fred Blommestein, van" wrote: > > Joe, > > The CCTS team thought your example was not that fortunate, because a > "residence address" is not a different "kind" of address (like all > addresses it has a street, number, postal code, state, country, etc.) > but it represents another role of the address. Therefore they adviced to > define it as an ASCC between (e.g.) Person and Address. So in fact they > missed the point you tried to make because the example was unfortunate. > > You are right that abstraction above the level of CC is not supported by > CCTS. Even the level of abstraction of CC's (must they be implementable, > or are they in fact abstract classes) is still under debate among > implementers. Is this something that should be included in the CCTS specification rather than left to implementation? IMO, yes - but that's just one view. > In fact even some hierarchy between BIE's is not supported > by CCTS. I, personally, would like to be able to indicate that e.g. a > Health_ Insurance Policy_ Contract is a kind of Insurance Policy_ > Contract, and not just a Contract. CCTS at the moment only has two > flavors: CC's and BIE's. Absolutely - including this functionality in the spec would be very beneficial, rather than leaving it to implementation "interpretation". > Note however that abstract classes by definition are not implemented. It depends on what one means by "implemented". > So > I doubt they will be useful in a registry that is mainly used by > automated systems. I respectfully submit the contrary - it would be very useful to store an abstract ACC in an ebXML Registry so that "assemblers" (people) could use it as the basis for derived ACCs. > No one forbids you to store the UML Class diagrams > (as pictures) in the registry to assist modelers and developers though. Absolutely - but for assemblers, that is very helpful only up to a certain point (the point at which they need the automated capabilities). Cheers, Joe > Fred > > -----Original Message----- > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > Sent: woensdag 28 juli 2004 17:54 > To: Schuldt Ron L > Cc: Bryan Rasmussen; ebxml-dev@lists.ebxml.org; > ebsoa@lists.oasis-open.org; Decapua David P > Subject: Re: [ebxml-dev] ebXML core components derivation by restriction > > Here is a specific example of what I was referring to in my posting > below: > > I expressed the following to the CCTS team in an "offline" e-mail, > regarding the fact that CCTS does not specify a facility for creation of > "abstract" ACCs (like abstract classes), and the derivation of other > ACCs from those abstract ACCs. My example was regarding Address: > > <Example> > This is an example of something that we may feel is necessary in our > registry architecture - for example, our "Address. Details" scenario in > which "Address. Details" may be considered an "abstract" > (base) ACC, and "ResidenceAddress. Details" may be considered a "real" > (derived) ACC that can be re-used in multiple ACCs as needed. </Example> > > Here is the response I received from the CCTS Team: > > <Response> > The CCTS does not support derivations of one ACC from another, like the > derivation of a real ACC from an abstract ACC. The Address example is > not that fortunate as such "derivation" can and probably will be solved > by means of ASCC's. Another example is a "Buyer Party" that may be > derived from a more generic "Party". Though it is tempting to define a > "Buyer Party" as a special case of "Party", this can only be done > "off-line", in the discovery and harmonisation process. The registry > should not take such derivation into account. Suppose later one adds > some property to the "Buyer Party" and not to the "Party", or deletes a > property. That would be allowed according to CCTS and consequently > should be supported by the registry. </Response> > > I believe that this scenario is not covered by ASCCs, as the CCTS Team > indicated, and requires functionality beyond that described in the CCTS. > > Kind Regards, > Joe Chiusano > > "Schuldt, Ron L" wrote: > > > > Bryan/Joe/et al. > > > > I concur with Joe's assessment that the current CCTS does not > > adequately address the need for core component extension. The need > > exists due to the simple fact that there is no such thing as a one > > size fits all purchase order or invoice or .. or .. etc. Too many > > industry-unique data requirements preclude one size fits all schema > > for most ebusiness transactions. Extensibility is essential at the > > core component building block level. > > > > If you agree with the requirement stated above, then a centralized > > online source and global registry for finding core component building > > blocks with the associated capability to extend those building blocks > > (as necessary) in a controlled fashion is an essential requirement. A > > proposed approach to this essential requirement is highlighted in the > > concept of operation (Figure 7) in the ebXML Forum article at > > http://www.ebxmlforum.org/articles/ebFor_20040306.html > > > > Ron Schuldt > > Senior Staff Systems Architect > > Lockheed Martin Enterprise Information Systems > > 11757 W. Ken Caryl Ave. > > #F521 Mail Point DC5694 > > Littleton, CO 80127 > > 303-977-1414 > > ron.l.schuldt@lmco.com > > > > > > > > -----Original Message----- > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > > Sent: Wednesday, July 28, 2004 7:10 AM > > 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 > > -- > Kind Regards, > Joseph Chiusano > Associate > Booz Allen Hamilton -- Kind Regards, Joseph Chiusano Associate Booz Allen Hamilton
<<attachment: winmail.dat>>