ebxml-core message

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


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: RE: Jon Bosak's suggestion that xCBL be adopted as the ebXMLBusinessDocument 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

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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC