Introduction

During the last year, dozens of articles have been written in the trade press about the possibility of using the World Wide Web's latest markup language, XML (eXtensible Markup Language), as a standard data format for electronic data interchange (EDI). This paper will explore the arguments for and against using XML in EDI as a new data exchange standard.

EDI: Historical Background

Ever since the introduction of digital computers for business applications in the 1950s, business firms have sought cost savings and greater efficiency through using these computers to perform repetitive clerical and computational tasks. The development of large computer databases in the 1960s and fast, reliable electronic computer networking in the 1970s and 1980s have made it possible for companies to streamline business-to-business transactions by using electronic data interchange (EDI) between corporate databases. By the mid-1990s, handling these transactions through EDI was becoming the norm for large and medium-sized corporations.

EDI had one major hurdle to overcome before it could be widely used: it required a standard data format. Without a common language, different companies using different brands of mainframes and proprietary database software could not read each other's data, making EDI impossible.

In response to this need, two standards were created. In 1979, the American National Standards Institute (ANSI) released the first version of X12, which became the standard EDI format in North America. At about the same time, the European Community released its standard, the Guidelines on Trade Data Interchange (GTDI). In 1987, the International Organization of Standardization (ISO) released a new European standard, EDIFACT, which combined concepts from GTDI and X12. Currently, X12 is the most commonly used North American standard, while EDIFACT is the most commonly used European standard (though it is also used by some American companies and, most notably, by some agencies of the American federal government).

As EDI use has become more widespread, CIOs have been calling for more flexible standards which reflect the variety of businesses which use EDI and the variety of data which they transmit through it. The Accredited Standards Committee X12 (or, ASC X12), which is the body in charge of reviewing and revising the X12 standards, has responded to these requests by broadening the data element dictionary that is the foundation of X12, but such alterations are a relatively slow process in the context of a fast-moving global economy. What many CIOs want in this economic situation is a user-extensible EDI standard.

EDI: How It Works Now

An example of company-to-company electronic data interchange:

Company A needs to order a product from Company B. Its purchasing department uses a template in its database application to fill out an invoice, then uses a custom EDI application to encode the database form into an EDI document, using either the X12 or EDIFACT standard. The encoded document is then sent to Company B over a private value-added network. Company B uses its own custom EDI application to convert the document into a form its own database application can use, sends an acknowledgement to Company A that the invoice was received, and begins the process of preparing the shipment.

This example demonstrates why EDI use has been restricted to large companies until recently: only a company with a substantial sales volume and a large number of orders to process could justify the expense of acquiring a custom EDI application and renting a private value-added network. A method of EDI that could make such costly items unnecessary could expand the market for EDI to mid-sized and small businesses.

The eXtensible Markup Language

In the 1970s, librarians, archivists, and hypertext writers began to see a need for a "markup language," which would allow computer users to describe the contents of their text by "tagging" "containers of text" and thereby make it easier for others to display the text, search the text, and understand its meaning.

This interest led to the 1986 establishment of the Standardized General Markup Language (SGML) by ANSI. SGML defines several thousand kinds of text and provides the tags to denote them. So, for example, if a piece of text is a citation, SGML notation allows the writer to put a tag at its beginning and a tag at its end, thereby denoting the piece of text as a unified element that is a citation.

When Tim Berners-Lee invented the World Wide Web in the early 1990s, he devised a (much smaller!) variant of SGML called the HyperText Markup Language (html) to be its lingua franca. As the Web has grown and the purposes for which it is used have varied, Web designers have become highly frustrated with the basic limitations of html, and have called for a new variant of SGML to be created to allow for more flexibility.

That new variant is called the eXtensible Markup Language (XML), and its specifications were approved by Berners-Lee's organization, the World Wide Web Consortium, in December 1997, and published in February 1998. Unlike html, XML is a true markup language, meaning that it merely describes the structure of the text without decreeing how it should be presented (users of XML can use separate "style sheets" to direct presentation).

XML also contains most of the useful functionality of SGML, while not being burdened with its more arcane tags and requirements. As one XML developer put it, "XML contains the 20 percent of SGML tags that are used 80 percent of the time." This streamlining makes XML much easier to implement than full SGML would be.

The other large advantage that XML has over html is that it is user-extensible. In addition to the full range of XML tags, hypertext writers can also define their own tags, as needed. (However, only the original XML tags will be universally interchangeable -- someone else who wants to read your special tags will have to install the same definitions as yours.)

Netscape and Microsoft have both released beta versions of the XML parsers which they plan to include with Navigator and Internet Explorer, respectively, so widespread XML development for the Web should begin within in a few months. Also, several companies have released XML browsers, parsers, and other developmental tools, some of which will be described below.

XML and EDI: How they would work together

The key phrase that leads many developers to think that XML and EDI are made for each other is "data container." The purpose of XML is to define containers of data (and remember: its tag library is user-extensible). The purpose of EDI is to transmit well-defined containers of data. Proponents of using XML as a markup language to provide a structure for EDI messages argue that XML is not only perfect for the purpose, but is also the future language of the World Wide Web.

XML's future (or lack thereof) as a widespread Web language is the key to its attractiveness as a standard for EDI. An EDI document structured in XML does not require a custom-built application to decode; a Web browser will be able to read it and display its contents, just as it reads and displays any other XML document. EDI documents structured in XML can also easily be sent over TCP/IP "extranets," which are much cheaper (though also less reliable) than value-added networks. By lowering the amount of money businesses interested in EDI have to spend on translation programs and data processing specialists, an XML standard will make EDI more economical and a reasonable option for even small companies.

Another factor in XML's favor is its extensibility, manifested in two ways. First, businesses are free to create whatever tag definitions they need to adequately describe their data. Second, other data standards can be encoded into XML format, meaning that XML can serve as a meta-standard that can read documents encoded in any other EDI standard.

XML's Web heritage offers one more e-commerce benefit to businesses as well: companies using XML as their EDI data standard will be able to integrate customer orders received through the World Wide Web with EDI orders from other businesses, because both can be sent in the same format. By combining these two ordering systems into one, businesses can decrease their overhead and increase their efficiency.

XML and EDI: Current and planned implementations

Given the benefits that XML can offer as a standard data format, it is not surprising that several products and projects exist or are planned to take advantage of its capabilities.

The most important projects underway are those which seek to ensure the backward compatibility of XML with prior EDI standards, and which seek to ensure that user-extended tags do not provide inconsistent definitions for similar items.

The backward compatibility issue is currently being addressed by the XML/EDI Group, which is writing up a proposed "Guidelines for using XML for Electronic Data Interchange" to submit to the World Wide Web Consortium. The XML/EDI proposed guidelines for formatting currently support X12 and EDIFACT documents as well as the inclusion of non-proprietary tools.

The RosettaNet group has been formed by 28 companies covering all areas within the information technology field in order to provide a consistent set of tag definitions for standard types of data (such as part numbers). Though the impetus for the formation of the RosettaNet group was the impending use of XML for EDI, it also seeks to rationalize electronic commerce standards in general.

In addition to standards work, early versions of several XML-related products are also available:

• DataChannel has released an XML Development Kit which provides a data router and parser for XML code, support for application-to-server direct publishing, and support for legacy integration.
• WebMethods, a company specializing in SGML support, has released a cross-platform integration server that uses XML and HTTP to transfer data between a variety of proprietary databases.
• Another long-time SGML vendor, OmniMark, is targeting owners of large Web sites with Konstructor, which uses XML structured objects to create Web page content from an underlying database.
• Digitome, an Irish company, has developed an XML-based set of type definitions called NFF which can translate data from a variety of programs so that it is readable in Lotus Notes.
• Junglee Corporation has taken advantage of the structured data that the XML standard provides to build a "virtual database" utility which can gather like data (such as part prices) from a number of different Web sites, so that users can compare them and find the best deal.

XML is also beginning to gather the essential element for any computer technology: a user community. CommerceNet runs XML Exchange to allow XML users to discuss various uses of the technology, and the Usenet newsgroup comp.text.xml was approved last month.

Conclusion: Will XML succeed?

There is little doubt that XML will play a major role in the continuing development of the World Wide Web. Microsoft and Netscape have committed themselves to supporting it in their browsers, and it is the basis for the new multimedia markup languages SMIL and PGML.

But will that Web growth translate into widespread use in electronic commerce and electronic data interchange? Computer people seem to unanimously think it will -- XML for EDI seems like one more milestone in the long road toward open, flexible, extensible, standards-based computing. Business people are more reserved.

The major hurdles that XML backers need to clear before they can gain unreserved support from businesses are backward compatibility with the existing X12 and EDIFACT standards and a full range of electronic commerce applications. As noted above, both of these hurdles can be cleared, and work is being done in those directions.

However, traditional EDI vendors are not sitting still as XML/EDI support increases. For example, some X12-based applications can now be used over the Internet (or any TCP/IP network) rather than over a more expensive value-added network. Also, some EDI vendors are learning to pool the resources of several small companies so that all can save money by sharing a common network. If traditional applications can continue such innovations and continue to hold their edge over their XML counterparts in speed and efficiency, then it might be some time before XML-based EDI solutions become the norm.

That time will come, though, for two major reasons. First, XML will make EDI integration with the World Wide Web and Web-based commerce seamless. Second, XML will make it easier for small companies to set up their own EDI capacity. Traditional EDI vendors such as Sterling Commerce and GEIS are already working on XML projects, and that migration will pick up speed as corporations begin requiring even their small suppliers to use EDI. The market for using XML for EDI exists and is growing, and XML will be a widely used standard in EDI within five years.

Sources