OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

Title: 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 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
"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
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC