[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: How to Create an ebXML Order (EDI 850 transaction set)
John: I was unaware of the "direct" capabilities of XEDI that you mention, but I still have some concerns about what XEDI is... (1) Not everything in the X12 and EDIFACT standards is a "core" construct that will further the ebXML vision. The Core Components group did a ton of work identifying the needed semantics as opposed to those that are legacy bloat, unused, etc. And yet, you seem to be advocating abandoning this work and simply taking the whole lot on again, a huge job of filtering and harmonization. It will be far easier to take a somewhat stripped-down view of EDI standards semantics, already organized into a component library, and build them up to be what they need to be in conjunction with the JCC work. Hence, xCBL. Also, it is somewhat worrisome that using XEDI would become a so-far-unresolved discussion about whether or not X12 or EDIFACT was "better". They have their differences, and that is one set of arguments that I really don't want to inherit when I'm trying to get a business vocabulary deployed quickly. Despite the harmonization efforts to date, they have different syntactic and semantic structures. In building xCBL, we had to do a lot of harmonization work around things such as code lists, and this was a non-trivial effort, even when we had subsetted which code-lists would be used. In many critical areas, xCBL has already performed this harmonization, generally by identifying and removing overlap to the extent possible, but it uses codes a lot less than either X12 or EDIFACT. (2) Because XEDI is modelling constructs designed to be expressed in EDI syntax, it sacrifices much of the power of XML schema languages: for example, local renaming versus typing (even with a "segment_DTM" element, I still have a child giving me full semantic qualification in the form of a code. Far better to have the full, local semantic qualifier at the top level when developing with tree-based/object-based technology such as current XML tools. Encapsulation is a standard part of OO, and yet you have modelled it out of the picture!) The way XEDI models this stuff, you have thrown away the benefits of using easy things like XPath and XSL by requiring that everything be qualified by it's children, with the efect of multiplying lines of code in an XSL stylesheet by the number of possible qualifying codes. Ow. (Not impossible, but difficult and unneccessary.) xCBL, being written natively in an XML schema language, does the correct kind of encapsulation while still retaining the needed type information. (3) The management of a core library - particularly when you are dealing with things like managing extensions for processing at run-time - is very tricky, especially when you're dealing with XML schema, as opposed to DTDs. xCBL has benefitted from looking at how this is done with EDIFACT, and UBL can no doubt improve this further. I feel that ultimately xCBL is the best example we have of an XML-schema-based vocabulary that addresses not just the issues of data modelling, but the management and coordination aspects of using XML schemas. No-one else has as much experience doing this, and it is reflected in the way the componentization is done. Historically, the model used was EDIFACT, modified to handle many of the new issues brought to the table by the use of XML schemas. XEDI doesn't have this history - it is a simple, DTD-based reflection of what is in an EDI vocabulary. Whie this is a good base, it's not enough, and not what xCBL has to offer. I guess I simply don't agree with you: I feel like many aspects of typical XML libraries are evident in xCBL but are lacking in XEDI, even simple things like having intuitive tag names to people who are not already EDI experts (albeit these will, in UBL, change to reflect the ebXML naming conventions). I am, no doubt, prejudiced, but then, so are you, so that's pretty much equal. What I will say is that I have yet to see you present a compelling argument for using XEDI as a base vocabulary for doing UBL. I do see XEDI as a useful part of a transformation solution, and that is a non-trivial thing. But I don't buy that it is a better place to start than xCBL, if only because it does nothing but inherit it's good properties from EDIFACT and X12, which are things we've already taken advantage of in the ebXML work. xCBL can offer a little bit more than that, since it brings some others considerations around schema management and XML design to the table. No doubt we will have a chance to continue the discussion... Cheers, Arofan Gregory -----Original Message----- From: John Evdemon [mailto:email@example.com] Sent: Thursday, July 19, 2001 10:59 AM To: Gregory, Arofan; 'Welsh, David'; 'Duane Nickull'; firstname.lastname@example.org Cc: Kevin Kail; James Blakeney Subject: RE: How to Create an ebXML Order (EDI 850 transaction set) On Tuesday, July 17, 2001 5:31 PM Gregory, Arofan wrote: > > Let's say that I have a "tax" section in a business message, and I am > required to supply either a simple VAT tax amount OR a tax rate, a tax > amount, and a tax type identifier. > > I can model that as follows: > > <!element Tax (VAT | (TaxRate, TaxAmount, TaxTypeIdentifier)> > > Now, it is perfectly conceivable that I can express the same information in > an EDI message, and document these dependencies in an implementation > guide. > I can even write the application code to make sure that when I get that > message, it will check to make sure that these business rules are followed. > > But, what I cannot do with XEDI is have a generic XML parser tell me that > the message is invalid, because of it's built-in enforcement of the business > logic ("business semantics") encoded in the DTD: > This is a gross misrepresentation of the capabilities of XEDI. XEDI can use ANY XML parser to enforce the structure and semantics of the message. You are only explaining the "indirect" approach which only enforces structure, not semantics (see my previous message for an explanation of the difference). Most of our clients use the "direct" approach, allowing them to validate structure and semantics with any "generic" XML parser. > If I have: > <Tax> > <VAT>3500</VAT> > <TaxType>ExportTarriff</TaxType> > </Tax> > > in my XML message, this is gibberish: I am giving an amount of VAT, and > then > telling you that it is an export tarriff, which it is not. There is an > internal inconsistency in my message. A generic XML parser can enforce the > simple business logic described above (the semantic content of my data > structure) because I modelled it into the DTD. I get an error, explaining > that I cannot have *both* a VAT element and a TaxType element, which is > indeed the source of the ambiguity here. This is an interesting (if overly simple) example. Listed below is a portion of a Value Added Tax Declaration Message. As you can see, the information model can be used to validate both the structure and semantics of the message (despite your claim to the contrary). Also note that the element names comply with global standard e-business naming conventions. Each element includes attributes containing metadata associated with the standard (enabling both EDI and non-EDI users to parse and understand the markup). <!ELEMENT Transaction_VATDEC ( Segment_UNB, Segment_UNG?, Segment_UNH, Segment_BGM, Segment_DTM?, Segment_LOC?, Loop_NAD+, Loop_AUT?, Segment_UNT, Segment_UNE?, Segment_UNZ)> <!ATTLIST Transaction_VATDEC desc CDATA #FIXED "Value added tax message" version CDATA #FIXED "D99B"> (Note: the Value Added Tax Declaration Message is one of several thousand global standard e-business messages that are not supported by xCBL.) > > XEDI does not let me do this: I need an application that understands the > relationships between the various segments and values as made explicit > only > in my implementation guide. Consequently, I have to buy a validator or write > the code to enforce these business rules. > Wrong again. The portion of the DTD listed above can be used by any "generic" XML parser to validate a Value Added Tax Declaration Message. We have DTDs/Schema available to validate the structure and semantics of any standard e-business transaction with a "generic" parser. There is no requirement to buy a proprietary validator or any additional software - any validating XML parser will work. > What the XEDI DTD describes are the *structural* components of an EDI > message ("segment," "loop"), and the XML parser does structural validation > on the message for me. (It can tell me if I am missing a "segment", but it > can't tell me which segment I am missing.) > Wrong. See my previous message explaining the differences between the "direct" and "indirect" approach. You are describing the "indirect" approach (which only validates structure). Again, see my previous email that explains the differences between the two approaches. The "direct" approach supports both structural and semantic validation. > This is the primary difference between a XEDI approach and the type of > standard XML approach used in xCBL and many other XML busines > vocabularies. > Again, you are incorrect. XEDI is 100% compatible with the validation approach used by xCBL and other XML business vocabularies. XEDI validates both structure and semantics (as should any XML business vocabulary). XEDI is also available in DTD and Schema formats - no proprietary XML development kits, schema mechanisms or parsers are used or required for validation. > Structural validation is critical when I am doing transformation - and XEDI > gives me this, as well as a consistent XML format that is easier to process > than a flat-file. What it doesn't give me is any level of meaningful > business "semantic" validation: it won't tell me if the message is > gibberish, or if I have violated the basic business rules on which my > business application relies. > Again, you are wrong on this assumption. XEDI provides BOTH structural and semantic validation of any standard X12 or EDIFACT message (all versions are supported) using any validating XML parser. > The net result is that XEDI is too narrowly focused to be a solid basis for > describing the data structures with which we do business. > This statement is absolutely false and, given your familiarity with EDI, a bit disturbing. The data structures and metadata used by XEDI are the same e-business standards that companies have been using for the past several decades (EDIFACT and X12). This fact makes XEDI the ideal choice for describing the data structures with which we do business because the data structures in XEDI ARE the way companies have done (and will continue to do) e-business. Unlike other markup initiatives, the data structures and metadata used by XEDI is derived directly from existing global e-business standards. Leveraging existing standards enables XEDI to support the 3,000+ standard transactions (and metadata naming standards) that companies have used to conduct e-business for decades. xCBL is incapable of supporting the breadth of standard e-business transactions provided by X12 and EDIFACT. Building UBL on top of xCBL will require duplicating the benefits that the XEDI approach delivers today. Any new standard (such as UBL) should leverage, extend and support existing standards. X12 and EDIFACT are in far wider use than xCBL - the XEDI approach enables us to use these standards now (not 1-2 years from now). > What we want is > an > ability to agree on the packages of information needed for certain > components, and then build applications that can rely on having those sets > of data present. > Better yet - leverage the existing global e-business standard packages of information that have been defined and used for the past several decades. This approach guarantees compatibility with existing e-business infrastructures and provides a broad, highly mature set of metadata for defining additional transactions (although the vast majority of e-business transactions are already available within the X12 and EDIFACT standard). Why re-invent the wheel? > XEDI cannot give us this without requiring a separate set > of code to perform validation that you can get free from any validating XML > parser, assuming you have written your DTDS or schemas correctly - that is, > to capture the semantic relationships between explicitly labelled pieces of > business data. > This statement is false - I assume it is because you are (again) unfamiliar with the XEDI "direct" approach. XEDI's "direct" approach uses information models that can be used to validate both structure and semantics with any validating XML parser (no need for proprietary schemas, development toolkits or vendor-specific parsers). > My basic argument is simple: XEDI is a useful tool, but it is the wrong tool > for the task at hand. > XEDI can be used to represent any X12 or EDIFACT e-business transaction (any version) as XML - with no loss of data. This is most definitely not the case with xCBL (since the vast majority of global standard e-business transactions simply aren't available). This fact hinders xCBL's qualifications as the basis for UBL because xCBL fails to comply with (or support) existing global e-business standards. I'm sure that xCBL was designed with the best of intentions (since xCBL s probably one of the best markup initiatives to support the indirect materials market). xCBL is not, however, capable of supporting the vast majority of standard e-business transactions that have been in use for decades. > The semantic content found in X12, UN/EDIFACT, and > other business vocabularies is hugely valuable, but it's up to us to model > it in a way that gets the most out of XML technology. > XEDI provides BOTH semantic and structural validation with any validating XML parser. XEDI also supports all versions of existing global e-business standards. xCBL provides 41 non-standard transactions while XEDI supports over 3000 global standard e-business transactions (all of which preserve the standard e-business metadata defined and supported over the past several decades). The tool of choice for developing UBL should be somewhat obvious when the facts are known and understood by all participants.
Powered by eList eXpress LLC