OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [ebxml-dev] ebXML core components derivation by restriction

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]