RE: Jon Bosak's suggestion that xCBL be adopted as the ebXML BusinessDocument framework

["Probert, Sue" <Sue.Probert@commerceone.com>]

Excellent thoughts, Stephenie.

What you also highlight is the importance of globally agreed definitions for
individual semantics. I have many similar implementation experiences and
offer up bill of lading number as a classic case in itself. Depending on the
mode of transportation, the country, or countries or the terms of delivery
etc. this one piece of semantic data can be called many different names e.g.
airwaybill number, CMR number, railway consignment note etc. etc. 

In reality there will be only one of these reference numbers per consignment
and the generic semantic definition could be agreed globally as something
like 'transport contract reference number'. This is what we are trying to
sort out as part of the ebXML CC work. We want to obtain the best generic
globally acceptable name and definition for each piece of semantic data and
then enable the specification of business synonyms for all the different use
cases including language variations where appropriate. If we can then
associate a global id number to each piece then we can greatly simplify the
mapping processes and work to a converged future between business process
definitions and syntax implementations.

In EDIFACT alone this would mean that we could then delete many of the 1153
codes which have been added to cover each individual business synonym and
simply use only the generic one for 'transport contract reference number' in
the future.

Sue

Sue Probert
Director, Document Engineering
Commerce One
Tel: +44 1332 342080
www.commerceone.com


-----Original Message-----
From: COOPER,STEPHENIE (HP-PaloAlto,ex1)
[mailto:stephenie_cooper@hp.com]
Sent: 02 April 2001 19:45
To: 'Philip Goatly'; John McClure; 'ebXML Core'
Cc: Peter Guldentops
Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the ebXML
Busi nessDocument framework


Hello.

I'm quite behind on all of what's going on at ebXML, so forgive any
ignorance.  At most, I've only been able to skim through messages during the
last 18 months, just in case it ever became part of my job to pay attention.
Well, looks like this is about to happen (and I'm in a state of total terror
and panic - what you all worked on all this time is stuff I have to come up
to speed on overnight!)

Regarding the EDIFACT standard, which is a good one that has served us well
up until now, I'd make some caveats regarding the number of
segments/elements, etc., that are required for a robust core dictionary.

Caveat 1:  X12 and EDIFACT have both suffered simulataneously from
redundancy and insufficiency.  

Example:  EDIFACT has three Credit Advice messages.  On the other hand,
there's no message (as far as I can tell) for transmitting a Bill of
Materials to a partner.

Example:  The EDIFACT code list 1153 for references includes an "ON - Order
Number [Purchase]" and "OP - Original Purchase Order".  Name someone who
hasn't gone through the exercise of interpreting which is which.  On the
other hand, I can't find a code in 1153 that I would use to uniquely
identify a Bill of Materials.

Caveat 2:  Related to Caveat 1 ... the X12 and EDIFACT dictionaries
currently contain message/segments/elements which represent *historical*
intercompany exchanges.  In the world of the virtual enterprise, an lot of
processes that we previously considered to be intracompany have and are
becoming intercompany processes.  Not only that, but companies are looking
for standards to use as intracompany standards for exchanges between
applications, having realized that, as Gartner predicts, the enterprise is
so complex that it is not possible to quickly converge on a single
enterprise-wide data model and therefore converge to a single
enterprise-wide business application.  So, what does all this do to the
count of necessary core components?  How much of this world have xCBL, OAGI,
RosettaNet, etc. addressed?

Caveat 3:  Name/Value pairs (code lists):  One element in X12 or EDIFACT or
any other standard may really represent a whole bunch of elements.  Quite
likely, a code that made it onto a code list represented a distinct data
element in someone's back-end system.  How many name/value pairs are just
auxilliary information, and how many really represent key back-end systems
drivers?

Example:  "Invoice Number", "Packing List Number", "Consignee's Shipment
Reference Number", and "Bill of Lading" number on a code list look like
harmless references.  Then you begin and implementation and discover that
the seller's system revolves around packing list number, and has no way to
obtain/assign a bill of lading number, and that the buyer's system revolves
around the bill of lading number as the key identifier.  This example is
taken from real life.  Coming up with a shipment identifier that everyone
agreed on proved to be impossible, so we had to resort to ye olde "We're the
customer, and this is what you're going to send in the ship notice" school
of e-bullying.

I think most of the breakdown in communications occurs when you get down to
elements and codes, because that's where you *discover* the underlying
business models that led to the designs of the back-end systems.  When I say
"back-end systems", I also mean any "off-the-shelf" solution that may be
purchased by an SME -- someone somewhere designed the solution (or is
designing it right now), and we can only hope that it involved business
users, not just modeling experts. 

Regards,
Steph.

P.S. Does anyone have suggestions for the order in which I should approach
the existing ebXML documentation in order to come up to speed efficiently?
Thanks.

-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Monday, April 02, 2001 3:04 AM
To: John McClure; 'ebXML Core'
Cc: Peter Guldentops
Subject: Re: Jon Bosak's suggestion that xCBL be adopted as the ebXML
BusinessDocument framework


Hi there,

    Just as a matter of fact:

    The latest EDIFACT standard has

      157 Segments
      200 Composite Data Elements
      640 Dta Elements

Let us talk facts - ther are many myths about EDICAT and thousands of
segments ;-)

Cheers, Phil
----- Original Message -----
From: "John McClure" <hypergrove@olympus.net>
To: "'ebXML Core'" <ebxml-core@lists.ebxml.org>
Sent: Saturday, March 31, 2001 2:51 AM
Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the ebXML
BusinessDocument framework


>
> Hmm, with over 600 DTDs in the xCBL distribution file, and not knowing the
> total number of XML elements, I must admit my concern that this approach
is
> the traditional recipe for lots and lots of software, and that's
> unappetizing to the SME. Not meant as a flame, but rather to point out
that
> when an XML namespace is designed using a normalized model for data
> representation, far fewer element-types result, with less complexity, less
> transforms, less software. Less hassle.
>
> To me, ebXML's approach is to create a repository where is stored a
> canonical data model reflecting its application-document domain.
> Unnormalized XML namespaces are (with help) mappable to such a model, and
> vice versa, i.e., the so-called 'generated DTD'. Thus, ebXML remains
> agnostic about the XML elements designated as standards by industry/market
> groups.
>
> Eventually, we'll see how normalized the ebXML model is. So far, I am not
> particularly encouraged, what with examples like "PartyDetails" and
> "PartyID". My hope is that the model is one that uses inheritance
liberally,
> knowing how that saves us all alot of coding. Further, I hope that ebXML
> establishes a set of XML elements that correspond to its canonical base
> entity classes, meaning that there would be a base namespace of something
> less than 100 XML elements. Speaking for myself, I surely don't relish the
> thousand XML elements found in namespaces like xCBL. I can deal with
> thousands of dictionary entries -- if they're organized -- by sticking
> subsets into pulldowns at the appropriate spots in my applications. But I
am
> most definitely troubled by the thought of a thousand XML elements
becoming
> a world-wide standard. EDI failed IMHO because people like me did not want
> to learn a thousand 'segments', sensing a self-appointed priesthood
existed
> around that standard. I urge you not to repeat history by having an XML
> element set that has over a thousand elements in it.
>
> Regards,
> John
>
>
> ------------------------------------------------------------------
> 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

------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org