[Asking on the listserv in case others may have the same question] Thanks Fred. Is there a formal Change Request document? Or will an e-mail suffice? Joe "Fred Blommestein, van" wrote: > > Joe, > > >> 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. > > Sure, if you think that is useful, please submit a change request to the editor, Mark Crawford (MCRAWFORD@lmi.org), with cc's to Alan Stitzner (Alan.Stitzer@marsh.com) and Mary Kay Blantz (blantz@attglobal.net). And I also would be much obliged to receive a copy. > > >> 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". > > Please see my previous mail and support us (TBG17) implementing hierarchy. > > >> 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. > > You convinced me :-), please forward a change request. > > 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 -- Kind Regards, Joseph Chiusano Associate Booz Allen Hamilton
<<attachment: winmail.dat>>