Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Why EDI Must Die

EDI doesn't have to be ripped out at the roots from every location and business currently using it, but long-term, EDI lacks the general-purpose data format capability that data exchange requires, so companies that rely on electronic data interchange are slowly but surely adopting XML instead—and rightly so, despite some problems.

lectronic Data Interchange (EDI), a data format used for inter-business messaging, has been partially responsible for reducing costs and increasing productivity in the manufacturing and services industries. Over the years, EDI has evolved into a mechanism for integrating back office systems and communication with business partners that has served its users well; however, it has inflexible, inherent, and practical problems that put a ceiling on its usefulness. To improve on the cost savings and productivity increases that EDI provided, it's time to find alternatives and begin to retire EDI. The obvious alternative is XML, which is a maturing technology that solves many, if not all, of EDI's problems. EDI's Problems
EDI is a special-purpose format. EDI's intended purpose was to provide a common messaging standard for businesses to communicate with other businesses. Rather than having to deal with a different data format for each trading partner, all businesses could convert their proprietary data format to EDI to send or receive messages and then convert EDI to their respective proprietary formats. EDI is an unlikely choice for a use other than inter-business messaging.

In contrast, XML was created as a general purpose data format that can be used to encapsulate any type of data. It can be used for inter-business messaging, application integration, protocol wrappers, data storage, object serialization, etc. Because of its generic nature, XML has been subject to the broad adoption that typically leads to faster technological advances, strong support from a large user community, and creative uses that get back-populated into the community. EDI lacks obvious looping declarations. The only looping constructs in an EDI (X12) document that explicitly mark the beginning and end of the loop (from outermost to innermost loop) are the interchange, functional group, and transaction set (where the transaction set contains the body of the business document). Looping occurs within a transaction set when a segment that is defined as the beginning of the loop is encountered and ends when no more segments defined in that loop are encountered. The looping is obvious in the document's structural definition, but less clear in the actual document. This separation of structure from data increases the level of difficulty required to properly extract information from an EDI document.

EDI's separation of structure from data increases the level of difficulty required to extract information from EDI documents.
Unlike EDI, XML has real nesting at all levels of a document. Every XML element has a start tag and an end tag (sometimes, they are the same tag) in which obvious, recognizable looping occurs. XML eases the ability to correctly ascertain the nesting structure of a document. EDI has no standard parsing API. The lack of a standard parsing API is a severely limiting factor. Anyone who wants to parse EDI data and extract information from it must either reinvent the wheel, as it were, or purchase either an expensive EDI mapping application or a third party library for parsing EDI.

Although XML is a much younger format, it already has DOM, SAX, XSL, XPath, and XQuery and each API has been implemented—often several times—for most major programming languages. To parse XML data and extract certain pieces of information from it or transform it to a different data layout, all you have to do is pick a mainstream language, choose an API supported by your chosen language, and start writing code. Your have myriad options—and most are free. EDI causes vendor lock-in. Those who continue to use EDI usually end up relying on a particular EDI vendor for software to manage their EDI and are, therefore, "locked in" to that particular EDI vendor. EDI vendors are essentially the sole providers of software tools for EDI. This is another option-limiting position to be in.

In contrast, tools for XML are created by the same community that utilizes XML. Many, if not most, XML tools are free and open source. One need not be bound to specific vendors to create a successful XML implementation.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date