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

[Philip Goatly <philip.goatly@bolero.net>]

Hi William,

     I agree with you completely

"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."
>
    One of the problems with EDI is the lack of business semantics above a
certain level in the 'data hierarchy' which seems to me to be a symptom of
the lack of an underlying daya model.

e.g at the bottom level we have the Data Elements then the Composite Element
and then the Segments - so far so good.

      Higher thant this we have Groups (of segments) without any consistency
across the documents/messages.

      Indeed a consistency at this level is virtually impossible since each
document 'reveals' only part of each 'data object' and some masking
mechanism would be required in a data model to reflect this.
     In part, the partial view of each object derives from where each
message occurs within a trade chain so only a few of the 'object properties'
of many of the objects is known at the outset of the transaction and -
hopefully at the end all the data has been 'filled in'. Another reason for
different views is the different context of the messages e.g. geography,
industry etc. but this is catered for by MIGs  which change the 'objects' to
individual context but at the price of lack of interoperability.

All for now

Cheers, Phil




----- Original Message -----
From: "William J. Kammerer" <wkammerer@foresightcorp.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Wednesday, May 02, 2001 7:53 PM
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
>