In my haste, i omitted the discussion list from my reply to this thread,
so here it is....
Mike, let me thank you for stirring up the myriad of hornet's nests with your
article (excellent, once again!). the debate on these various lists would
be poorer without you.
i would like to keep the UBL library content team's profile fairly low at
this stage. we are trying to digest the work load ahead and its unwise to
make a strong position on anything. however, i will give you my personal
assessment and the answers i would give if this came up in a UBL meeting.
firstly, what you have stated is a reasonable description of our purpose,
but may lead to a false impression about the role of xCBL. we are not terribly
interested in harmonizing xCBL, in fact xCBL can do whatever it likes. our
BIE library will be expressed in XML as the UBL vocabulary. it will undoubtably
not be backward compatible with xCBL, nor does it need to be. this point
emphasises that UBL is not a xCBL initiative - its just that, given all the
choices of starting places, this was deemed most practical (i did not say
'valuable' or 'technically correct' or 'politically acceptable'). Rather
like your writings, we needed to draw some lines in sand and attract debate.
with respect to ebXML Core Components, your second sentence beginning "There
is a UBL subcommittee..." may be misleading. we are not delving into the CC
catalog itself. we will submit to ebXML CC, a set of BIEs and the context
drivers that refine them. your subsequent sentence (beginning "In this process..."),
describes the situation perfectly.
i am glad you raised the question of code sets. in EDI structures, i felt,
there were always two type of code sets. Firstly are the codes that encourages
adoption of externally recognised values for element (ISO 3166 Country codes,
UN/LOCODE, etc..). The others were introduced as implementation features
to avoid having restrictive sets of element names (your example of the Buyer
code is a good one). Using these implementation specific codes meant the
designers could tack on other codes without having to change the element definitions
(eg somebody realises the need for a 'person to blame' party can have the
'PTB' code added without breaking the standard).
it occurs to me in thinking more deeply about this, that the first situation
is a case of providing an unambiguous description of an object. for example,
it seems sensible to have <country ISO3166="NL"> rather than <country
name="holland"> or <country name="netherlands">. to use UML jargon
(correctly, i hope!), the class is "COUNTRY", but the object is "the country
known as either Holland or the Netherlands (in english speaking countries)".
i think the second situation is different because we are actually trying
to describe an associated hierarachy of classes. 'party' is actually a generalisation
of 'buyer', (or, as you stated, 'buyer' is a type of 'party'). as such 'buyer'
will inherit some values from a 'party' (maybe 'contact details') and have
its own as well (maybe 'credit limit'). this seems logical because 'buyer'
is a class not an object. however, rather than attempting to define all these
sub-classes, the EDI solution has been to allow extendible lists codesets
to define the sub-classses. with the entensiblily of XML, we dont need to
adopt such complexities.
i suspect this is why you can have <party paryRole="buyer"> sensibly
expressed as <buyer>, but <country ISO3166="NL"> expressed as
<Holland>, loses its meaning. it also means if trading partners want
to use the XML tag <PersonToBlame>, good luck to them!
all this leads me to suggest that in the Library Conent work we shall be
basing the design decisions on what the actual BIE or aggregate BIE is (i.e.
the conceptual model of the data), rather than the implementation expression
in a particular syntax.
thank you for teasing out the issue, it has allowed me to clarify the situation
and highlighted a strategy to follow, in my mind at least!
i welcome your comments.
Mike Rawlins wrote:
3C0595E4.B58140FA@rawlinsecconsulting.com">
James Bryce Clark wrote:
At 10:17 PM 11/27/01, Peter Olivola wrote:
As you noted, Mike, the bulk of the effort, whether EDI or ebXML or
Ewok,
still gets down to, in it's simplest terms, a definition of "ship
date."
That's not a technical issue now and no flavor of XML will make it
one. As
long as there is no agreement on common business terms there will be
little
advantage to one data format over another.
1. Peter is absolutely right.
2. Mike, or anyone, are those taxonomy issues in-scope for UBL? I
know you're defining a set of what xCBL calls "documents" but am less
clear about plans to specify default or required codesets -- NAICS,
UNSPSC, that sort of thing. Certainly they are a key piece of the Big
Puzzle.
3. And if there's an EwokXML, sign me up.
re: 2 - I'm not quite sure exactly how to answer this one, but here
goes. There is a UBL subcommittee that is doing a mapping from xCBL
elements to ebXML/CEFACT core components, and back again. In this
process they are identifying a set of business information entities
(core components used in a specific context) that will be the foundation
of the UBL "library", and will be submitted back into CEFACT. This
exercise will also help eliminate duplicates and do some other
harmonization in xCBL. Regarding codesets (code lists, enumerated
lists, whatever), there is a proposal to only use recognized external
code lists (e.g., ISO 3166 country codes), and not use EDI-style
internal code lists ("BY" in N101 means we have a Buyer name).
Elements would be named specifically rather than using another coded
element to specify the type (e.g., <buyer> instead of <party
partyRole="Buyer">)
That proposal
has not been discussed as yet.
Does this answer your question?
re: 3 I'm still working on WoofXML...
--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
.