Re: What do people really expect from ebXML? - Whatever it is,it better be easier than EDI

["William J. Kammerer" <wkammerer@foresightcorp.com>]

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"