RE: What do people really expect from ebXML?

-----Original Message-----
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: 03 May 2001 17:52
To: 'martin.me.roberts@bt.com'; 'ebXML Core' (E-mail)
Subject: RE: What do people really expect from ebXML? - A way forward ->

I agree with much you have written, however I don't agree with the assessment that domain specific context is too hard in a cross-industry setting. Hard? Yes! Most things in life are hard. Too hard? NO!!! That is what the EWG/X12 core components initiative is all about. Please join us as we take the building blocks of ebXML and move them from a concept to a robust CC library that covers Core and Context in a true inter-industry approach and as our BP counterparts in EWG and X12 leverage those CC in their modeling efforts.

BTW, there is a very strong possibility that in EWG we will also be working with noted XML experts in developing XML instantiations of the JCC catalog.

Mark
Mark Crawford
Research Fellow - XML Lead
E-business Strategies
______
Logistics Management Institute
2000 Corporate Ridge, McLean, VA 22102-7805
(703) 917-7177 Fax (703) 917-7518
Wireless (703) 655-4810
mcrawford@lmi.org
http://www.lmi.org
"Opportunity is what you make of it"

> -----Original Message-----
> From: martin.me.roberts@bt.com [mailto:martin.me.roberts@bt.com]
> Sent: Thursday, May 03, 2001 7:20 AM
> To: wkammerer@foresightcorp.com; ebxml-core@lists.ebxml.org
> Subject: RE: What do people really expect from ebXML? - A way
> forward ->
>
>
> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>

ebxml-core message