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

[David Lyon <djlyon@one.net.au>]

Todd, you wrote:

> 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.

You're absolutely right...

And we should also remember that the Stakeholders of ebXML are the people
that contribute honest money from all around the world which then goes to
the United Nations. This includes people in places like Asia, Europe, the
Americas, Africa and the Pacific. They are the stakeholders of ebXML.

I think your comments would go down well with these people. Maybe
development of ebXML should be shifted closer to developing countries where
the need for ebXML is more acute. I'm sure that India, Australia, Thailand
or Singapore would be ideal candidates to develop this simple vocabulary
rather than keeping it in first world countries like Austria, Germany and
France who really have little if any motivation to demonstrate tangible
results.

It appears that the ebXML focus has been more centred to date on drinking
fine champagne in Vienna than building the marketplaces that they talk about
on their home page. Of course, let bygones be bygones, and there is always a
chance that ebXML can take on a more meaningful existance in the future. I
wouldn't give up hope.

Take care

David


----- Original Message -----
From: Todd Boyle <tboyle@rosehill.net>
To: ebXML Core <ebxml-core@lists.ebxml.org>
Sent: Sunday, May 20, 2001 10:05 AM
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
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>