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

["COOPER,STEPHENIE (HP-PaloAlto,ex1)" <stephenie_cooper@hp.com>]

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