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

[John McClure <hypergrove@olympus.net>]

Thanks Philip,
and regrets to all for my sometimes impolitic/imprecise way of putting
things.


I am trying to square your definition of a segment, composite, and data
element with Todd Boyle's definitions. Todd points to far far more semantic
entities than the numbers you are quoting. For instance, he claims that
there are 549 different types of documents. From what I've seen in xCBL, an
XML element-type is defined for each type of document. It is that design
approach -- aligning element-types with semantic types -- which I find
deeply troublesome. That's why I wrote the memo.

My hope is that ebXML establishes a hierarchical data model, together with a
set of canonical XML elements corresponding to its base classes. It would
then be unsurprising to me if 15 or so base classes emerge, and thus 15 or
so element-types are defined. These base classes and element-types *are*
resource-types, thus tying in with RDF and the Semantic Web.

Thanks,
John
> -----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
> >
>
>