RE: Oooh - Ouch! Is it necessarily the Truth if it Hurts?

[Todd Boyle <tboyle@rosehill.net>]

William J. Kammerer says the DAMSAD Project Group doesn't like ebXML
"representation types" and prefers the formal definitions of the type
supplied in XML Schemas as recommended by the CWA.

They are confused.  Representation types are independent of XML schema
datatypes, i.e. there's no conflict, they're complementary, and all that.

DAMSAD reportedly also said ".... The poor quality of
the ebXML core components deliverables, however, precludes its
content from direct use in a CWA.  The confusion as to how and
when ebXML core component libraries will be created and managed,
how these will differ from ebXML Business Libraries, and how users
will access such libraries, makes it impossible to provide coherent
guidance on the management of semantics related to ebXML..."

DAMSAD: the EDI community has 400,000 sites running grammars in pairwise
connections that are working real well, other than the fact that 
they are not compatible with much outside their existing clubs of 
of two or more.

Therefore Core Components workgroup decided their job was building
a magical automapping facility that would recognize this status quo,
and help those 400,000 connect with more peers more easily.  As a
result they developed a complex specification which begins to analyze
the meaning of a data element (DE) first by considering numerous 
contexts such as geographic, industry, country, language, process
and product category of buyer and the seller.  

I am skeptical that even ten or twenty context drivers disambiguates 
the meaning of a DE, in other words it just delays the inevitable that
some of these entrenched EDI users will have to adjust some of their
vocabulary, someday.   (And once they fix one or two, these shops will 
be in good training condition to finish the job and search/replace a 
few more words in their danged setups.  :-)

In any case these context drivers certainly achieve a considerable 
increase in the namespace available for DEs.  (hmmm is that ten
factorial, or ten squared?  100 different meanings available now,
for "Address". YOWZA!  Now thats a spec. the EDI industry can love.)

The spec for COre components requires that the name of a DE be unique.
(I believe this is not true of classic 11179 registries.  11179 
registries seem to permit any o' thing as the descriptor of a DE,
and that it might even change after it is in use.  I could be wrong.)

The rest of ebXML (messaging, TP, BP, and reg rep) in my humble 
opinion have been more successful at defining something usable by
small and medium businesses.

In closing, I think the hard job of identifying a single vocabulary
for that horizontal layer affecting all industries has been shirked
by the ebXML, yeah I know it wasn't in the scope, but who decided
the scope? 

It is more urgent than ever that the leading business vocabularies
today, should go into a room someplace and agree to converge their
models and vocabulary for the broad horizontal layer.  And populate
the ebXML registry.  

In my opinion that's OAGIS, RosettaNet, and xCBL.  EDIFACT still 
being a hodgpodge, they aren't a factor in this job and actually 
seem to have negative incentives to converge on any single vocabulary,

Todd