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

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

Sorry folks
  EDICAT should have read EDIFACT !!

Cheers, Phil
----- Original Message -----
From: "Philip Goatly" <philip.goatly@bolero.net>
To: "John McClure" <hypergrove@olympus.net>; "'ebXML Core'"
<ebxml-core@lists.ebxml.org>
Cc: "Peter Guldentops" <peter.guldentops@bolero.net>
Sent: Monday, April 02, 2001 11:03 AM
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
>