RE: What do people really expect from ebXML? - A way forward ->

[martin.me.roberts@bt.com]

Dear all,
	We have seen that ranting going on about semantics for long enough.
I am sorry I can't be in Vienna but I suspect that some of this heat/light
needs to come out in the meetings there.

	The problem of matching two semantic domains so they can communicate
is hard.  The basic idea behind the CC is correct, i.e. try to define as
much as you can so that at least everybody can see a common dictionary of
'semantics'.

	Unforntunately XML as merely a form of syntax can not bring that
much to the table other than trying to use a set of element/attributes that
point back to the basic semantic CC.  However, the CC that have been
published so far only cover the building blocks for messages, and not the
semantic definitions of those building blocks when that appear in a
document, i.e. the difference between PARTY and SUPPLIERPARTY (deliberately
not naming standard compliant).  This is where William's and the David's
comments about RATES and AMOUNTS come into play because it is not until a CC
is used that it real semantics are understood.

	I have mentioned it before in this forum, but no one has pick it up
yet.  The Idea of Context adds a significant layer of semantics over the
core components.  This is NOT being nailed down by ebXML and therefore the
effect will be a set of almost semantic free objects (CC) and the freedom to
do with them as you see fit.

	The approach I am going to adopt is to use the framework for CPA, BP
and Messaging and then go back to my industry for the full set of Semantics.
I can not rely on a cross domain semantic model as I suspect any one
industry model is too complex in its own right.  Does this mean ebXML has
been a waste.  NO it has highlighted the problems of semantics and shown to
the powers that be that we have a difficult problem.  The technical
framework, will move the whole area forwards even if the CC ends up lagging
(because it is difficult) behind.



Martin Roberts
xml designer, 
BTexact Technologies
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 643775
fax: +44(0) 1473 646668



-----Original Message-----
From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
Sent: 02 May 2001 19:54
To: ebXML Core
Subject: Re: What do people really expect from ebXML? - Whatever it is,
it better be easier than EDI


David Powell would have us believe  "..... it is a quick and easy thing
for an XML coder to map the names they use onto the names offered by
their trading partner.."

Well, David, if it were that "quick and easy," then nobody would've
complained about EDI - why, it's just a matter mapping this field to
that field!  Surely it can't be a matter of the asterisks and other
delimiters that makes EDI hard, because a mapper insulates you from
those petty details.

I think my example for David Lyon yesterday regarding OBI's simple
purchase order illustrates the problem:  How do you know which of my
names is the same as his names?  I had to make assumptions, which I
glossed over, when "mapping" Lyon's simple invoice line item: what did
he mean by "code" - I guessed that it was the vendor part no., but by no
means am I sure of that.

And what did he mean by "rate"?  Actually I had no idea, but since he
omitted "unit price," I made another assumption that "rate" was a
synonym of "unit price."  Was the tax a rate or an amount?  Since he
didn't explicitly say rate, I made another assumption.  Can I always
expect the quantity * unit price + tax = amount, or are there some other
assumptions and tricks?  Was Lyon's "description" really a product name,
as I assumed?  What were his "comments"? I didn't say yesterday, but I
assumed that it must've been an extended product description, even
though it could just as easily have been shipping and handling
instructions!

This is a lot of assumptions to make, and just for a simple invoice line
item.  The only way to be sure we're talking about the same things is
for David to do a better job of documenting, or for me to call him up,
where we both lose all solution scalability if we have to do that with
each and every trading partner.

Sue Probert's business about "fixing semantic anchors" with UUIDs, or
some other artifact like normalized labels from the BSR or BSI/BEACON,
is necessary so I can be sure Lyon's "description" is the same as my
"product name."  EDI solves much, but not most, of the problem simply by
having rigid names and dictionaries and code qualifiers: had I never
seen the OBI documentation, I still would've have properly interpreted
an OBI  PO instance with no ambiguity.   The same is not true if David
Lyon had sent me an instance document containing his line item "tags" -
at least not without making the assumptions I did.

If the document were any more complicated [than a simple invoice line
item], with only loose tag names like those provided by Lyon, then I'm
very confident in saying I'd much rather have a big putrescent pile o'
EDI land on my lap: at least I might have a fighting chance of
interpreting its meaning without having to go back and forth with the
sender.

Listen folks:  whatever we come up with had better be a darn sight
easier than EDI - and merely "readable" tags just ain't going to cut it.

William J. Kammerer
FORESIGHT Corp.
4950 Blazer Pkwy.
Dublin, OH USA 43017-3305
+1 614 791-1600

Visit FORESIGHT Corp. at http://www.foresightcorp.com/
"accelerating time-to-trade"



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org