[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Oooh - Ouch! Is it necessarily the Truth if it Hurts?
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
Powered by eList eXpress LLC