XML to the Rescue?

August 4, 1999

Alan Kotok

XML, with its ability to transfer structured data over the Web, immediately attracted the attention of people and organizations struggling with traditional EDI. In August 1997, as XML had begun to emerge, David Webber and Bruce Peat, two of the founders of the XML/EDI Group (which later became a special membership organization of the GCA Research Institute) explained how XML could transmit structured data like those carried in EDI:

An EDI application for XML provides the structural complexity that supports and parallels today's EDI transaction sets. XML provides a rich document structure that can be nested to any level of complexity. With XML, our documents are like chameleons, capable of being processed by different components, delivered by different mechanisms, and displayed to the user in different ways.

By using the XML extensible tag set, EDI "objects" can be either passed or dynamically referenced to objects stored in repositories. The XML/EDI Group is proposing the use of XML as a "carrier" for the document information so that the transaction can carry not only data (like trad-edi), but also code (at each level in the transaction tree). With an element having data properties and code methods, this allows the business elements to be manipulated as "objects". [Note: object inheritance is slated to be incorporated in a later version of XML.] In XML, each document is an object and each element of the document is an object.

The logical structure of the document and tag set can be specified in a Document Type Definition or DTD. (The best-known example of a DTD is HTML, which is defined by a DTD describing the structure of HTML documents.) In a DTD, sets of elements and their attributes are defined; the names that are used as tags are assigned; and the element relationships or transaction is defined. If a DTD is used then programs can validate the transaction's structure. You can validate the structure of an XML/EDI document automatically. If this sounds complex, it is not. Defining your own markup language (DTD) with XML is actually surprisingly simple. (XML/EDI Group web site, www.xmledi.com/)

"The business model of the Web stresses inexpensive and even free tools, so the economics of XML held out the promise of extending the benefits of EDI to smaller companies."

Moreover, the business model of the Web stresses inexpensive and even free tools, so the economics of XML held out the promise at least of extending the benefits of EDI to smaller companies with considerably less pain and expense of traditional EDI. At this point, the economics of XML appear to be moving in that direction. The W3C and groups developing specifications for XML applications make these documents available free of charge over the Web. One can find XML software tools for free or nominal costs from several vendors. Leading web browsers available now (or soon) for free or nominal cost support XML. Internet service providers offer connections for low monthly rates, and stiff competition in the field promises to keep rates low, even as bandwidth expands over cable and fiber-optic lines.

XML appears to solve the problem of differing North American vs. international standards found in EDI. The ubiquity of the Web and relative ease of connections worldwide has made development of XML and its various applications international exercises. The XML/EDI Group and CommerceNet, two of the standards groups working on XML/EDI guidelines, have active European and Asian chapters as well as North American participation. IBM, Microsoft, iPlanet (the Sun/Netscape alliance), and most other leading vendors are truly international companies with a stake in preventing national or regional conflicts in standards.

XML also appears to better handle the problem of integrating data from EDI transactions into corporate systems. EDI transactions move door-to-door, that is from the sender’s mailbox to the receiver’s. When a transaction arrives, EDI translator software strips away the X12 syntax and presents a flat file that the receiver’s systems need to parse, check for accuracy, edit, and distribute. Enterprise management software will often include these functions with the package, but most of these packages are priced well beyond the resources of small and medium-sized companies. For smaller organizations, they either need to write custom handlers or print-and-rekey, two less desirable options.

Using XML, enterprises have more options for the display and processing of incoming data. The Extensible Stylesheet Language (XSL) allows for the visual display of incoming data and formatting of those same data for further processing by corporate systems. In addition, more end-user applications packages already or plan to support XML that enables the recipients to capture and process the incoming data directly. Even with legacy systems, industry groups can specify standard scripting language or Java code that reflects industry rules, to provide for greater mapping and integration of data exchanged over the Web with XML.