Hi Joe, Please do put your request in a MS Excel spreadsheet with columns: Line/paragraph number, Present wording, Proposed wording, Reason for change. This is by no means an official statement, as the UN can never impose some commercial product (like MS Excel). But you drive Mark crazy by submitting in another format (and that doesn't help the speed of processing it :-) Fred -----Original Message----- From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] Sent: Wed 28/07/2004 21:39 To: Fred Blommestein, van Cc: Schuldt Ron L; 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 [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>>