Document Software Strategies Analysis

Vol. 2, Number 29
- August 15, 1997 -
copyright (c) 1997 by CAP Ventures

Accelerating Electronic Commerce:
Making EDI Accessible with XML

by Mary Fletcher Laplante


In the last two articles in our series on XML from a market perspective, we looked at early developments in the tools arena primarily from the vendor's perspective, covering topics such as initial advantages for SGML suppliers and the role that the HTML authoring tools companies may (or may not) play in the XML software space. This week, we went back out to the user community in an attempt to uncover opportunities arising from early implementations of XML beyond those on which we've reported to date, such Microsoft's Channel Definition Format and the various metadata standards that are in the process of being re-formed as RDF. Who else is doing cool things with XML? In particular, who's doing cool things that present opportunities for technologies like document management, repositories, retrieval engines, and workflow, in addition to browsers and authoring systems? And who's doing cool things that could be translated to real dollars in the near term?

As it turns out, one XML application that fits this criteria is, in fact, about dollars. This fourth article in our series looks at XML as an enabler of electronic commerce. It describes the activities of the XML/EDI Group, an ad hoc confederation of technology professionals who want to build better commerce and transaction solutions, and it highlights opportunities for document technology suppliers as traditional EDI systems and methodologies are replaced by or updated for use on the Web.



Our XML Xpert of the Week is Bruce Peat, unofficial spokesperson for the XML/EDI Group. Peat's day job is systems analyst at Datamatix, a Pennsylvania company that serves as a purchasing facilitator between suppliers and government agencies at the federal, local and state levels. In addition to filling us in on the activities of the XML/EDI Group, he also provided background on the larger issue of the relationship between existing EDI systems and methods and the realities of conducting electronic commerce on large-scale wide-area networks like the Internet.

In simplest terms, according to Peat, the big problem is that the formal EDI standards that exist today, such as UN/EDIFACT and ANSI X12, were developed twenty-five years ago. New business practices, the development of global economies, and advancements in computer technologies are just several of the factors that have made those standards unworkable and unimplementable for many organizations (only 100,000 companies worldwide today use EDI, which is rather surprising for standards and technologies that have been in play for a quarter of a century). For one thing, the existing EDI standards accommodate point-to-point transactions only -- which presents problems for a "middle man" company like Peat's. For another, as with many "standards," actual implementations are typically customized to suit specific application requirements. With EDI, such customizations are embodied in Implementation Conventions, or ICs. In many instances, ICs have become barriers to effective data interchange. Different ICs on the buyer and seller sides of the transaction make for data that's not interoperable without translation or conversion of some sort.

The costs associated with addressing these and other technical issues, along with software licensing fees and the cost of applications development, can make EDI prohibitive, especially for small to mid-sized companies. When they do have to implement EDI in order to maintain supplier relationships with big companies like Wal-Mart or Chrysler, the systems often have just enough technology legs to satisfy contractual arrangements. They can also be limited in terms of extensibility to Web-based electronic commerce.

This is not to say that existing EDI standards and technologies are completely outmoded -- they are not. They obviously support many efficient and effective EDI systems at the 100,000 companies that have implemented them. But they do present certain constraints to the 100,001+ companies that want to or could participate in electronic commerce activities. Finding ways to deal with these constraints is how Bruce Peat found other technology professionals and document standards folks with a similar interest in developing new approaches to transporting transaction data. They set up an informal electronic community as a means of sharing information and exploring standard solutions, now known as the XML/EDI Group (check out its Web site at



The XML/EDI Group's philosophy encompasses the notions that documents are an integral part of commerce activities and that effective solutions are those that integrate EDI activities directly into the workflow that drives business processes. Given this philosophy, requirements include a standard document encoding scheme for data interchange, the ability to automatically transport dynamic business information, tools that are capable of processing the data encoding scheme, and open APIs that allow for rapid, easy integration. The Group believes that an XML application and associated XML software tools will address these requirements.

The standard that the Group is developing is also called XML/EDI. It is an XML-based data interchange application primarily for Web-enabled commerce (interface with legacy systems, existing databases, and conventional client/server architectures are design goals). It defines a standard for encoding the presentation characteristics, structure, and behaviors of data that supports business transactions (such as catalogs, order forms, and healthcare claims). Its purpose is to facilitate the exchange of transaction-critical information and, therefore, the automatic execution of document-based transactions. The general idea is to add enough intelligence to the documents so that they -- and the document-centric tools that handle them -- become the framework for electronic commerce. This is a departure from traditional EDI systems, which tend to focus on transport only rather than the entire business process that drives a transaction from start to finish and are typically built with relational databases as the core technology.

There are several consequences of using a document-centric approach. Documents (which are part of the business process anyway) can be made to drive transaction and commerce processes rather than just support them. Transaction-related documents encoded in standard ways can be searched, manipulated, and displayed correctly by anyone with access to the right tools, bringing them closer to their companies' key business activities and enabling more efficient processes. This could lead to reduced EDI administration, making the overall costs of electronic commerce more affordable for more companies.

Using XML as the specification language offers another set of benefits. First, it provides a way to extend existing EDI applications. XML tag sets can be based on the EDI dictionaries and ICs that already define the elements and templates of the transactions in a particular application, and there's an affinity between XML trees and the relational database structures that currently describe many EDI applications ("it's a perfect fit - like RNA and DNA," says Peat). Second, XML enables fielded searching for faster and more efficient information retrieval. Third, it supports the development of dynamic repositories; no longer do EDI applications have to be "shoe-horned" into fixed element dictionaries or templates. By using XML and the W3C's Document Object Model, Java code can be attached to transaction elements, allowing for dynamic display in Web browsers. Fourth, XML-encoded data can be processed by machines as well as humans, which enables the automation of data transport through a workflow (and the development of interoperable catalogs, about which we'll write in the future).

The concepts behind the XML/EDI Group's document-centric approach to electronic commerce aren't new. Researchers at De Monfort University Leicester, the University College London, and the Document Interchange project at UKERNA reported results of their Joint Electronic Document Interchange (JEDI) study about a year ago. They concluded that the combination of structured presentation with structured data for transactions was a viable alternative to traditional EDI and that SGML, along with the DSSSL standard, was ideally suited to the task. But an SGML/DSSSL approach was and is a very hard sell. XML's ease-of-use, its orientation towards delivery of networked information, and the support it's getting from the big players in the Web technology market make it a much more acceptable solution.

With the broader accessibility of XML and the fact that EDI is already used by thousands of companies both large and small, Peat believes that a commerce application such as the Group is developing will find acceptance. He may have reason to be optimistic -- the list of organizations that have joined the Group's discussion list within just the last month includes Walt Disney Imagineering, AT&T, the International Monetary Fund, Motorola, Bellcore, GE, and Oracle.

(Note that there are user companies participating in the discussion as well as technology suppliers.) Endorsement by the W3C will help, too.

The Group plans to submit its specification to the standards organization, which is already engaged in a joint project with CommerceNet related to automatable payment selection processes (the Joint Electronic Payment Initiative). And speaking of CommerceNet, we understand that it is also working on an XML application for electronic commerce. On the quotes page at the XML/EDI Web site, there's this from CommerceNet Group: "We are already working on it." Another intriguing hint: Terry Allen, one of the primary developers of the Davenport SGML application and an influential figure in the standards arena, is now on board at CommerceNet Group.



Document-centric commerce initiatives like those of the XML/EDI Group, if successful, will give applications developers and integrators new tools for building new approaches to EDI that aren't possible today. Suppliers of document technologies that previously have had little direct application to electronic commerce solutions will find new opportunities. And small to mid-sized companies that haven't been able to afford EDI systems will be able to participate in electronic commerce activities. Because we're already seeing these companies come into the document technologies market, the accessibility of affordable commerce solutions that are document-centric may accelerate their entry.

If you're interested in following XML/EDI development, we suggest that you subscribe to the Group's mail list, which you can do from the Group's Web site. If you decide that document-centric commerce solutions are a market opportunity for your company, you might want to follow Peat's advice: go out and find yourself an EDI vendor with whom to partner. The EDI companies will have contacts within the installed base of EDI users, and they'll have the integration expertise to build new commerce solutions that include your tools. As Peat put it, with their understanding of ICs, EDI dictionaries, and transaction workflows, "the EDI vendors become the knowledge base for the integration."


Mary Fletcher Laplante
Director, Document Software Strategies Group
E-mail: [email protected]

CAP Ventures, Inc.
600 Cordwainer Drive, Norwell, MA 02061 USA
Tel: +1.617.871-9000 ext. 184
Fax: +1.617.871.3861