OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Jon Bosak's suggestion that xCBL be adopted as the ebXMLBusinessDocument 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
> 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
> 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
> 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
> most definitely troubled by the thought of a thousand XML elements
> a world-wide standard. EDI failed IMHO because people like me did not want
> to learn a thousand 'segments', sensing a self-appointed priesthood
> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC