[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 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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC