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

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

The main problem is that object oriented people were not brought up this


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


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 
> reference:
> 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
> derive by restriction, eliminating the element referring to
> from the myns:MyOrderType, then derive by extension adding an element
> refers to myns:MyPartyType.
> "

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton

<<attachment: winmail.dat>>

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