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

[John McClure <hypergrove@olympus.net>]

Philip,
Youre right that more modelling seems to be needed. As I earlier noted,
looking at the world in terms of data components is pretty low on the
semantic stack. At some point, it may be more clear that an *object model*
has to come out of the work. That is what RDF Schema elements are used for.
And that is what XML Schema accommodates (albeit through single inheritance
only). It's more than just a list of data elements, folks, associated with
document-types. And is the dictionary going to become ISO compliant, and
maybe use DAML to express constraints and relationships? Who is supposed to
make that decision? I also sometimes wonder about why the RegRep's APIs
don't do XML...

These are the sorts of thing software developers look for in ebXML. This
thread surprises me because it talks about SMEs, but it's really the SME
software developer, aka the software components industry, that is the
primary target for ebXML's product, not their customers. In fact, I haven't
seen any publications' "Intended Audience" mention end-user customers.
Regards,
John

> -----Original Message-----
> From: Philip Goatly [mailto:philip.goatly@bolero.net]
> Sent: Thursday, May 03, 2001 4:53 AM
> To: William J. Kammerer; ebXML Core
> Subject: Re: What do people really expect from ebXML? - Whatever it
> is,it better be easier than EDI
>
>
> 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
> >
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>