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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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

Subject: RE: [regrep] Core Components Riddle

my comments in the text below...

De : Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Envoyé : mardi 5 avril 2005 00:38
À : regrep@lists.oasis-open.org
Objet : [regrep] Core Components Riddle

Now that our V3.0 specs are in OASIS public review, I have a general question on Core Components please:
The basic question is: What precise value do Core Components bring for data exchanges?
More details:
Scenario #1:
- Suppose 2 trading partners are exchanging data.
- Also suppose that none of the Core Components that are used in the exchange are part of the TBG17 Core Component Library (this will be the variable for the next scenario).  
[IB] No, I can't belive that ;) 
The solutions are:
1) if yours BIEs are enough generics you could consider to ask to TBG to process your business requirements and to start the standardization process. For that is enough to presents two documents. One decribes the BP features of your business (the BRS Business Requirement Specifications) and the other one (the RSM Requirement Specification Mapping) describes yours business documents in UML format (these documents are often already part of the business specifications)
2 ) if yours BIE are too specifics and they do not need to be globals you can define yours business documents using CCTS rules. (which is likely a good format to define business exchanges)
- The sending trading partner decides to indicate in their XML document the various Core Component entities (CC's, BIEs, etc.) using a content model (set of elements/attributes) near each entity (where does not matter - but let's assume just below) that indicates what type of entity it is.
- The receiving trading partner processes the XML document, but does not process the entity information because all it "cares" about is the actual data, not the data model. What value does using Core Components bring here?
[IB] CCTS doesn't provide tools for that yet. it only describe how to modelling yours data and rules, after you have some rules to transform that in xsd format (see the NDR document). Actually you have to develop yourself the content validation. as David suggests CAM could provide this feature.
Scenario #2:
- Same as above, except that all of the Core Components that are used in the exchange are part of the TBG17 Core Component Library (and stored in the UN/CEFACT Core Component registry - assume it is in production), and are indicated as such using their registry identifiers. 
([IB] It will come ...)
- The receiving trading partner processes the XML document, but should they "care" about the entity information this time? What value does using Core Components bring here? Is it different than the value in Scenario #1? 
[IB]  I don't understand your feel. isn't it an implementation issue ? 
A third question: Absent any data exchanges, what would motivate someone to "Core Component-enable" all of their data? (for example, creating a relational representation of the CCTS Core Component entity metadata, and populating the tables/fields with the metadata values + the original data). 
[IB] In my experience I see every time a new way to describe business data, and every time I spent some time to understand how they are built. After that I've to understand how they are transformed in xml or other, how they are stored and of course I spend some time to find information.... (and of course this implies that someone has spent time to do that)
The ebXML framework will provide tools for develop, manage and implement business data (see the UN/CEFACT Registry effort for example) and it will decrease the investiments efforts to bring up new trading exchanges.
Could it answer to your questions?!?
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com

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