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 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
Powered by
eList eXpress LLC