n an article published last week on DevX entitled “Why EDI Must Die“, the author, Jeremy Jones, gives several reasons why he believes XML is superior to the X12 format for electronic data interchange. He points out several shortcomings of X12 and several arguments as to why XML is a better choice.
But the article gives short shrift to X12 EDI, which has proven itself thanks to years of industry-wide use and reliability, and which continues, today, to be a mature choice for data interchange. The author seems to lack a true understanding of the technological advantages of X12 and the true reasons for the industry’s slow migration to an XML format for use in EDI in the future. I am not attempting to convince the reader that XML is a poor choice for EDI, but rather to give X12 a fair perspective compared to XML.
Point by Point
I’d like to step through the author’s arguments one at a time, explaining why I believe there’s another side to this story.
EDI is a Special Purpose Format
It is simply wrong to consider X12 a special purpose format. Today there are more than 300 transactions defined by the Accredited Standards Committee (ASC) that are used widely throughout many areas of industry. By design, X12 was intended to be a very open and extensible format for allowing businesses to exchange data electronically in a commonly understood format. Granted, the individual transaction sets defined by X12 are special purpose, but from a generalized perspective, X12 is very flexible and can be used to define transactions for nearly any purpose.
| Author’s Note: Electronic Data Interchange is not a standard, per se, but rather represents the concept of exchanging data and documents electronically. There are several specific EDI formats, including X12, but also HL7 in the healthcare arena and even XML. In this article, I will be distinguishing specifically between X12 and XML. |
One obvious sign that X12 is more mature than XML is the time-tested modular design of the format. X12 has defined many segments that can be used generically to represent similar abstractions, such as people and events. For example, in X12, anytime an NM1 segment is found in a document, any X12 parser recognizes the segment as the “Individual or Organization Name,” and can parse it accordingly. Transaction sets can modify various characteristics of the segment to make it more applicable for the specific purpose, but in general, it is easily recognized and parsed.
Various working groups, such as Oasis, are working to define similar abstractions that can be used in a modular fashion in any XML document. A great deal of progress has been made toward this goal within the XML community, but the X12 community has brought a much greater degree of adoption and formality to the message structures.
Also, we will all find that any format that is widely adopted in an industry will become “special purpose” over time. When an entire industry, or even a small group of trading partners, agree on a format for exchanging data, the formats reach a higher degree of inflexibility because changes are costly and involve a great deal of coordination within the trading partner community. Practically speaking, X12 is not considerably more or less “special purpose” than XML because the X12 format is flexible in providing for specialized segments and transaction sets. Further, wide adoption of any standard?XML, X12, or otherwise?makes change in the standard difficult and costly.
EDI Lacks Obvious Looping Declarations
In his article, Jeremy Jones makes the point that X12 does not include obvious looping declarations and does not provide hierarchical representation of all data syntactically, as does XML. In fact, X12 provides the same looping and hierarchical functionality that XML does, but rather handles it semantically; in many cases, special purpose segments are used to declare the nesting and looping characteristics of the document. I don’t agree that there’s any issue of concern here at all?electronic parsing of documents negates the utility of ‘physical’ nesting and loops.
EDI Has No Standard Parsing API
In most X12 implementations, a parser is chosen to handle the translation of the documents and conversion into a format that can be used more easily by internal systems. In many cases, the translator/parser makes the data available in an object-oriented construct specific to the transaction set. The vast array of XML parsers are great tools and will serve to aid in the maturation of XML, but in the end, a mature outcome of any EDI format will be a parser or translator that makes the data available in a format most suitable for internal consumption of the data.
Many companies select a general-purpose parser that will parse a document and either transform the incoming document to a more useable format or make it available via a simple programmatic structure. The same will happen to XML, making the array of tools available for XML irrelevant for the developer. Essentially, the actual format of the document will become far less relevant than the selection of a tool for parsing the document. This will lead companies, even those that use XML, to purchase a parsing tool rather than custom-build (from the many XML tools available) a tool to parse EDI documents.
EDI Causes Vendor Lock-In
A well-designed architecture can prevent vendor lock-in. It’s true that any time you decide to purchase a parser or translator, as opposed to using a set of XML tools to roll your own, you will, to some degree, be ‘locked in’ to a particular vendor. However, by building modular systems that can adapt to vendor changes, vendor lock-in is not a major issue. Software architects have been working for years to prevent vendor-inflexible technology choices. This trend has been most obvious in regards to database platforms?by building a data tier into the architecture of the system, the customer becomes less dependent on the database vendor. In a well-architected system, XML does not help to prevent any level of vendor lock-in.
XML Is a Verbose Format
In an effort to dispel the notion that verbosity is a major detriment of XML, the author went to great lengths to describe the characteristics of network throughput and processing throughput. The data itself may be fine but the author 1) provides no comparison to equivalent X12 network and processing throughput, and 2) fails to recognize that network and processing throughput are not the only issues to consider when comparing the hardware impact of XML and X12.
For example, the author states that when sending 50KB XML files, 25 messages per second would be required to consume a 10Mbps network connection and would support about 2 million messages per day. But most connections used between trading partners are nowhere near 10Mbps. Notwithstanding the Wal-Marts of the world, most connections are sub-T1 speeds, with a theoretical maximum of about 1.5Mbps. Further, most businesses have a processing peak time?a period of 10 to 12 hours per day during which most transactions occur (there are some exceptions). In such a case, the theoretical 2 million messages per day figure drops to about 3 to 4 messages per second?or about 135,000 in a 10-hour period. And since, by the author’s own estimate, XML messages are about 25 times larger than comparable X12 messages, the number of X12 messages that can be sent, assuming similar network conditions, is about 3.3 million in the same 10-hour period.
The use of 9600 baud modems with X12 EDI reflects the maturity and longevity of X12. Modems are still used in isolated environments to support legacy frameworks, but most X12 is transferred over high-speed connections, just like XML. XML will be as mature as X12 one day and will carry with it many pieces of legacy memorabilia.
|
The author did not address the storage ramifications of using XML. In an environment where auditing and customer support concerns demand that messages be available online in at least near real-time, storage of XML, with 25 times more data to store, becomes an important issue. However, it’s true that when discussing the processing of just a small number of messages, the real performance distinctions between X12 and XML fade.
Right Conclusion, Wrong Reason
While I’ve taken a lot of specific issues with “Why EDI Must Die,” in the end, I do not disagree with the author’s basic premise: XML will eventually replace the standard field-delimited format of X12. XML has found wide industry support and is quickly gaining ground on supplanting the legacy X12 format. XML, with its support for schema definitions and freely available tools for verifying the structure and content of messages, along with its wide array of support for various parsing methodologies, will prove to be more robust. Further, as processing capacity, disk space, and network bandwidth become more affordable, many of the distinctions between XML and X12 will blur.
However, the EDI industry has not yet embraced XML to an extent that makes legacy X12 formats irrelevant. Most in the field of EDI can attest to the lack of trading partner support for XML. XML is a great choice for many applications, but for right now, X12 is still the best choice for many industry-standard EDI implementations.
