Re: Jon Bosak's suggestion that xCBL be adopted as the ebXMLBusinessDocument framework

[Philip Goatly <philip.goatly@bolero.net>]

Sue,

Yes indeed - and the 'Unique Identifier' for the Bill Of Lading can be
constructed from different data elements e.g. The 'Voyage Number + Vessel
Number etc.' or  'Year of Voyage + Sequence Number etc.'  etc. which is used
depends on the individual carrier.

What really matters is the fact that it uniquely identifies the Bill Of
Lading. If one were to allow for all the possible ways of identifying the
BOL as data elements, the individual 'in house systems' of the carrier/s
start to work their way into the standard !! which is not what I think we
want.


Cheers, Phil
----- Original Message -----
From: "Probert, Sue" <Sue.Probert@commerceone.com>
To: "'COOPER,STEPHENIE (HP-PaloAlto,ex1)'" <stephenie_cooper@hp.com>
Cc: <ebxml-core@lists.ebxml.org>
Sent: Monday, April 02, 2001 9:22 PM
Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the ebXML
BusinessDocument framework


> 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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>