regrep message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [regrep] Core Components Riddle
- From: "BEDINI Ivan RD-BIZZ-CAE" <ivan.bedini@francetelecom.com>
- To: "Chiusano Joseph" <chiusano_joseph@bah.com>,<regrep@lists.oasis-open.org>
- Date: Tue, 5 Apr 2005 11:24:33 +0200
joe,
my comments in the text
below...
Regards,
Ivan
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?!?
regards,
Ivan
Thanks,
Joe
Joseph Chiusano
Booz Allen Hamilton
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]