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

<Ron>If the ebXML CCTS building block registry is based on a taxonomy
(ontology) and associated OWL/RDF overlay rather than a rows and columns
matrix (the current CCTS approach), then the desired inheritance and
extension capability becomes possible provided the extension process is
well understood and properly managed by an appropriate global

Extension capabilities are provided. Any project can, through the
appropriate channels (contact your UN/CEFACT Head of Delegation) forward
proposals for new BIE's and CC's to the non-profit UN/CEFACT working group
TBG17 (harmonisation).
Wrt OWL/RDF, in my experience there are little non-academic souls on this
earth that really comprehend those standards (so much the same like CCTS
;-). I am not one of them (yet). Personally, I would love to see
convergence between the OWL/RDF ontology work and the CEFACT/OASIS Core
Components work. As far as I understood though, OWL/RDF is mainly related
to semi-structured data, while Core Components are applicable to very
structured data (even an SAP system must understand it ;-).
<Duane>Would this not be served by an iterative process according to the
methodology itself?  For example, a Health Insurance Policy Contract is
a specialized (in context(s)) instance of the type Contract, in itself a
specialization of "Agreement".  Through iterative revision, the high
level "contract" should have a notion of "type" with an enumerated list.
 The enumerated list may be conditionally validated [1] against other
qualifiers (something that XML schema cannot currently do) and "Health
Insurance Policy" is merely a type of contract.</Duane>

<Fred>I agree with the mechanism, but CCTS does not support it.
Enumeration is only supported at the lowest level, for data types, not for
aggregates. Conditions can be stored in the "usage rule" of a CC/BIE, but
that is free text for the moment. I would be in favour of defining an OCL
profile/subset for such rules, that also would be 1:1 translatable to

<Ron>If you agree with the mechanism and CCTS does not currently support
it, is there any reason that CCTS could not be changed and support it in
the future?</Ron>

I think the introduction of BIE hierarchy, either in the spec itself or in
the application of it like TBG17 adopted, plus the adoption of some OCL
profile to be able to state constraints and conditions would cover this

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Wednesday, July 28, 2004 9:54 AM
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

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:

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.

Here is the response I received from the CCTS Team:

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.

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
> 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
> requirements preclude one size fits all schema for most ebusiness
> transactions. Extensibility is essential at the core component
> 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
> Bryan,
> Commenting solely on the Core Components Technical Specification, not
> 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,
> > 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
> > 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
> that
> > refers to myns:MyPartyType.
> > "
> --
> Kind Regards,
> Joseph Chiusano
> Associate
> Booz Allen Hamilton

Kind Regards,
Joseph Chiusano
Booz Allen Hamilton

<<attachment: winmail.dat>>

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