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

[Tim McGrath <tmcgrath@tedis.com.au>]

i am not sure what the point being made is, but as an Australian who was
actively involved in ebXML standards development, i must explain something about
the process here.

if, by stakeholders, you mean those putting money into this, then you are
incorrect.  to my knowledge, the UN does not pay anyone, anything to do this
work.  all those involved pay their own way and give up their own time.  The
reality is that those making the financial investments here are the mainly
US-based technology providers.  the nett effect is that the UN gains
intellectual property from this work.  So we in India, Australia, Thailand and
Singapore (the 'second' world?) are beneficaries.  If you want greater
involvement then someone has to foot the bill.  perhaps you could lobby the UN
to encourage and sponsor participation from these regions?

More importantly, Todd is correct is saying there is benefit in those leading
business vocabularies today converging their models and vocabularies for the
broad horizontal layer and registering them within an ebXML registry.  This
could provide a 'proof-of-concept' to the ongoing work in the UN with its Core
Components and Business Process teams.  There has been such a forum mooted and I
think you will see announcements soon -  so pass the fine champagne and don't
give up on us yet!

David Lyon wrote:

> 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
> >
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142