Joe,
Ah! That is a horse of a different
question!!!
What you need for that is (of course) a weighted
score chart! ; -)
Somethings that go into that:
1) what does your currrent data world look like and
how much is it costing you?
a) you could control your own data
space and all your partners - therefore low value
b) other extreme - you have to
deal with hundreds of other agencies - all with their
own data
definitions.
2) are you trying to create a "plug-n-play" system
for 1,000s of external org's to
potentially interface to you
electronically? (paper reduction act drivers)
a) if so - how much does it cost
you to on-board each one?
b) look at XML2004 Interop
approach to solve this - with registry managed
services.
3) How big is your agency?
a) US Department for
Investigating Broom Handle Design Impacts
- ok -
probably a sledge-hammer to crack a nut
b) US DOD - no sledgehammer is
big enough - but you have to start
somewhere!
DW
----- Original Message -----
From:
Chiusano Joseph
To: David Webber (XML) ;
Sent: Monday, April 04, 2005 7:27
PM
Subject: RE: [regrep] Core Components
Riddle
<Quote>
Is that enough business
benefit level?
</Quote>
Not enough to (hypothetically speaking) convince a
US federal agency executive as to
why they should spend X thousands of dollars to have their technical folks
"Core Component-tize" a large chunk of their data.
:)
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: David Webber (XML)
[mailto:]
Sent: Monday, April 04, 2005 7:24
PM
To: Chiusano Joseph;
Subject: Re: [regrep] Core Components
Riddle
Joe,
Of course - I think the CAM executive summary
probably
covers this off in terms of building industry
dictionaries -
http://www.oasis-open.org/committees/download.php/5930/CAM%20Executive%20Overview%20brochure%2003Mar04.pdf
but in a nutshell- you go from the CCTS model
to the
business nouns in XML in the registry - that
now
gives you the industry dictionary - along with
re-use.
Your re-use improves as you enhance the
semantics
around the business nouns to include OWL based
definitions and classification schemes and
association
links - so the usual "see also", "associated
with", and
other tools become instanciated.
Of course the UBL approach - of publishing a
pre-defined
set of purpose built transactions also fits in
here. The
idea being to provide pre-done BPSS scripts,
CAM
templates, CPA partner profiles, and
UBL-structure
schema that allow rapid adoption.
Is that enough business benefit
level?
DW
----- Original Message -----
From:
Chiusano Joseph
To: David Webber (XML) ;
Sent: Monday, April 04, 2005 7:00
PM
Subject: RE: [regrep] Core Components
Riddle
Thanks so much David.
Additional opinions, including a "business benefit"
level?
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
From: David Webber (XML)
[mailto:]
Sent: Monday, April 04, 2005 6:53
PM
To: Chiusano Joseph;
Subject:
Re: [regrep] Core Components Riddle
Joe,
No surprises here. If you want to
couple CCTS to actual
runtime validation and content processing
then you
have to use technology such as CAM
templates - and
the associated business noun definitions as
XML
in registry - so that you now have direct
linkage
between the model definitions and the
runtime.
UBL have been finessing this by using W3C
XSD
to carry the structure information from the
CCTS model
with limited content
semantics.
This only gets you so far before you hit
insurmountable
issues relating to context and structure
permutations.
Not to mention codelist processing and
then
permutations based of codelist selections -
eg if
countrycode="US" then require ZIPcode, else
require
postalcode.
Then you have to use CAM templates to
resolve
and implement this.
Since CAM has been purpose built for
delivering this
for CCTS all along - this is a bit of a
non-surprise here.
DW
----- Original Message -----
From:
Chiusano Joseph
To:
Sent: Monday, April 04, 2005 6:38
PM
Subject: [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).
- 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?
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.
- 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?
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).
Thanks,
Joe
Joseph Chiusano
Booz Allen
Hamilton
Visit us online@ http://www.boozallen.com
