atom feed18 messages in org.oasis-open.lists.ebsoaRe: [ebsoa] RE: [ebxml-dev] ebXML cor...
FromSent OnAttachments
Schuldt, Ron LJul 28, 2004 7:17 am 
David RR WebberJul 28, 2004 7:37 am 
Chiusano JosephJul 28, 2004 8:54 am 
Chiusano JosephJul 28, 2004 9:55 am 
Duane NickullJul 28, 2004 9:55 am 
Chiusano JosephJul 28, 2004 10:02 am 
Schuldt, Ron LJul 28, 2004 10:08 am 
Chiusano JosephJul 28, 2004 12:38 pm 
Schuldt, Ron LJul 28, 2004 12:41 pm 
Schuldt, Ron LJul 28, 2004 1:39 pm 
David RR WebberJul 28, 2004 1:46 pm 
Carl MattocksJul 28, 2004 2:04 pm 
Schuldt, Ron LJul 28, 2004 2:51 pm 
Schuldt, Ron LJul 29, 2004 7:11 am 
Chiusano JosephJul 29, 2004 9:31 am 
Schuldt, Ron LJul 29, 2004 3:12 pm 
Schuldt, Ron LJul 30, 2004 10:05 am 
Duane NickullJul 30, 2004 10:43 am 
Subject:Re: [ebsoa] RE: [ebxml-dev] ebXML core components derivation by restriction
From:David RR Webber (dav@drrw.info)
Date:Jul 28, 2004 7:37:38 am
List:org.oasis-open.lists.ebsoa

Ron,

I've been playing this tune for 4+ years now!

Maybe finally people are ready to take this on-board.

Of course CAM is already fully equipped to provide exactly this functionality.

Hopefully we will be able to provide this as part of the eGov TC Registry project that is currently in progress.

All the technical pieces are in-hand. It really is just a case of using them - eg SCM noun definitions + Registry RIM presentation of CCTS objects + jCAM processor to provide context driven implementation layer integration.

Thanks, DW ========================================================== Quoting "Schuldt, Ron L" <ron.@lmco.com>:

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

-----Original Message----- From: Chiusano Joseph [mailto:chiu@bah.com] Sent: Wednesday, July 28, 2004 7:10 AM To: Bryan Rasmussen Cc: ebxm@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

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

http://drrw.net