Emery Kobor wrote: > > Chuck, > > In a previous discussion thread, the issue of ACH addenda record size came > up, and you noted: > > "ACH addenda records are of a fixed size, essentially > card image records, as in 80 bytes! However, you can have up to > 999 of them. This works (mostly) for EDI, but it's still not > enough for XML." > > How do EDI and XML compare, byte for byte, and what adjustments > might have to be made for "financial XML" to replace "financial EDI?" > > Regards, > > Emery Kobor
Emery, First, thanks to Rob Haller for correcting my earlier mistake regarding the number of ACH addenda records allowed. As he points out, the maximum allowed under current rules is 9,999. A quick answer to your first question: In general, you cannot compare EDI and XML documents on a byte for byte basis because of fundamental differences in the underlying syntactical models. However, for some common business documents, it is possible to compare the total size of a document expressed in EDI with its equivalent expressed in XML. Figures I have heard tossed around by people who have made these comparisons indicate that XML tends to be at least three times larger than EDI. This may not be a useful comparison, however, as I'll try to explain below. EDI and XML represent two very different methods for structuring documents. EDI was developed with the specific goal of standardizing an efficient means for representing traditional, form-oriented business documents, such as purchase orders and invoices. In general, EDI data elements are defined within the EDI standards, and are typically fixed lengths. However, groups of data elements can be repeated as often as necessary to generate a specific document. For example, the data elements comprising an item line on a purchase order could be repeated for as many items as are included in the purchase order. EDI also employs tags to represent data elements that are constrained to only a few characters, thereby sacrificing human readability for document efficiency. XML, on the other hand, is derived from the SGML document structuring language, and tends to use descriptive (verbose?) tags to identify data elements, and many data elements are of variable length. As with EDI, groups of data elements can be repeated as often as necessary, but the formatting rules are more complex and flexible. What sets XML apart from other document structuring languages is its extensibility. This is attractive for business documents since it allows a base document specification to be extended to incorporate new data elements or structures to address specific industry requirements. Coming back to the question of document size, it is feasible for an XML document to use short or abbreviated tags along with constraints on data element size to approach the space efficiency of EDI. It is even possible that the richer syntactical structures available in XML could be used to define some documents in a more efficient manner than EDI standards currently support. While there has been some talk of creating these "more efficient XML documents" (including from the ACH community facing the 9,999 record constraint), there does not appear to be much interest or strong demand for doing this in the current climate. XML documents are also easily compressed, which could be an option for using them in bandwidth or space constrained situations, but without having to redefine tags and element sizes. Of course, there are also situations where XML documents can be considerably larger than their equivalents in EDI--sometimes much more than a factor of 3. You also asked what "adjustments might have to be made for 'financial XML' to replace 'financial EDI?'" My own opinion is that there will probably not be any "adjustments" to the XML conventions that are being broadly accepted in the industry today. Efficiency is nice, but the current mood seems to favor flexibility and extensibility over space and bandwidth efficiency. True, there are legacy systems that have hard constraints, such as the 9,999 record limit in ACH. However, one must also consider the viability of using the ACH networks to carry business documents between trading partners vs. using the Internet or EDI value-added networks (VANs). My personal opinion is that ACH networks are not likely to be used to carry large, complex XML business documents. Regards... -- ...Chuck Wade CommerceNet "Setting the business agenda for global electronic commerce" +1 508 625-1137 Office Phone/Voice Mail +1 309 422-9871 Fax Service http://www.Commerce.Net/initiatives/sipayment/
