The XMLedi Group

The XML/edi Group

The XML/edi Group (www.xmledi-group.org) provided much of the early thinking on the use of XML for business data exchange, and continues to serve as a grassroots advocacy and self-help movement of people worldwide who care about XML's role in business. Many of the group's ideas have found their way into the ebXML specifications.

In the late 1990s, the XML/edi Group took advantage of the use of an email list server to bring together individuals widely scattered around the world, who could share ideas and collaborate on development projects utilizing XML. The list emerged as a critical tool for building a group dynamic, even among people who had never met each other, and enabled them to work together and contribute to complex development projects. Another well-known example of this phenomenon is the XML-DEV list, founded by Peter Murray-Rust and Henry Rzepa, which generated the Simple API for XML ( SAX ) protocol. (See Chapter 4 for a discussion of SAX.)

While trading partners may exchange XML documents, they also need instructions for processing the documents to extract the data.

The XML/edi Group follows much the same model. The group was founded by four individuals in Europe and the U.S., including one of the authors, in the summer of 1997, while XML itself was still in development. In June 1997, Bruce Peat, one of the group's founders, published a paper on XML/EDI, pointing out some of the advantages that XML brings to business data exchange. Peat's paper noted the following:[1]

[The] XML document can also be a transaction itself. XML/EDI would allow in a non-proprietary way, for structured presentation format to be included now in the transaction Soon there will be a standard with which to share the work others have done, applications need only to simply access WWW browser objects. This object-based approach to applications will make document transaction exchange even easier. Bottom line: The EDI camp could leverage XML to aid in lowering implementation costs.

Later that summer, Peat and David Webber outlined a framework in which XML can serve as a catalyst for e-business data exchanges. The authors noted early in the piece that "XML/EDI involves much more than just dropping EDI into an XML wrapper. An XML/EDI framework includes the use of a set of complementary and powerful technologies." These technologies include what Peat and Webber called "The Fusion of Five":

• XML

• EDI

• Templates

• Agents

• Repository

By templates, Peat and Webber refer to the rules expressed in a table containing the terms used in the message, supplemented by the DTD schema. The templates accompany the message, providing business meaning to the XML content. Agents act on the processing logic, and guide the end user through the business process (for example, with Java or ActiveX) to look up or attach the appropriate template or determine display characteristics of web-based forms. In this paper, the authors defined the repository as the semantic engine to connect terminology used by trading partners to a neutral syntax. This lookup function could also be assigned to the agents.

The paper noted as well the distinction between document-centric and data-centric models for exchanging business data. While trading partners may exchange XML documents, they also need instructions for processing the documents to extract the data used by the trading partners' applications.[2]

Another of the group's founders, Martin Bryan, drafted the XML/EDI Guidelines, with contributions from Peat,Webber, Beno t Marchal, and Norbert Mikula. This document provided more definition of these components and offered a process for implementing XML for EDI-style exchanges. Bryan proposed the use of directories to look up and verify trading partner capabilities. This discovery process became part of several later specifications, including those of ebXML.

The implementation steps recommended by Bryan included the following:[3]

• Identification of suitable data sets for electronic business transactions

• Development of DTDs that formally define the relationships of the fields that are to form a particular class of EDI messages

• Definition of application-specific extensions to standard message types

• Creation of specific types of electronic business messages

• Validation of the contents of messages

• Transmission and receipt of electronic business messages

• Processing of electronic business messages using data bots or agents

The ebXML technical architecture relies significantly on distributed registries and a registry information model that describes the functions of the APIs.

Members of the XML/edi Group took part in early attempts to define the direction of EDI, using the new XML technology. David Webber of the XML/edi Group, Robert Crowley of the X12 EDI standards committee, and Rik Drummond of CommerceNet formed an ad hoc task group in 1998 to define algorithms for generating XML elements from the X12 database tables. The task group wrote one of the first DTDs for a working EDI transaction (a purchase order), and provided some initial thoughts on the use of XML namespaces and repositories. The group also offered ideas on combining object-oriented technology with XML, a line of thinking that became much of the basis for ebXML.[4]

Another contribution of the XML/edi Group was its work on defining the role of repositories in business data exchanges using XML. In a 1999 white paper, Webber (with contributions from group members Betty Harvey, Denis Hill, Ron Schuldt, Martin Bryan, Dick Raman, and Gerard Freriks) spelled out the functions that repositories provide. Those functions include

• Identifying the data exchanged among trading partners

• Defining a standard structure and relationships of the data exchanged

• Providing connections to universal business or product identification databases such as UPC/EAN product numbers , or taxonomies such as the Universal Data Element Framework (UDEF) to encourage interoperability

• Determining authorized parties to the transactions

• Providing common mapping, scripting, workflow, or processing tools

• Offering standard forms and screen displays for human interaction

These repositories would therefore contain all of the objects companies needed to exchange data with each other, using an open , standards-based approach. They would include the business process designs, expressed as XML scripts and linked to the XML message structures.

Trading partners would interact with repositories using a software routine called an application program interface ( API ) that would allow either automated or human access methods . Companies would probably need to access several repositories; thus, the structure and API would need to be standardized. The paper recommended that industry organizations or agencies responsible for government procurement host these repositories.[5] The ebXML technical architecture relies significantly on distributed registries and a registry information model that describes the functions of the APIs, a model similar to the one outlined by the XML/edi Group.

The XML/edi Group's work on repositories inspired early research and development on an XML/EDI repository at the University of Denver's Daniels College of Business. Ren Kasan, a graduate student at the Daniels College, developed a prototype repository that stored business objects for exchange between trading partners. She enlisted the help of faculty member Don McCubbrey, as well as local EDI practitioners Ron Schuldt and Will Thayer, and relied to a large extent on the groundwork started by the XML/edi Group.

The work of the group, particularly through the efforts of European founders Martin Bryan and Beno t Marchal, had a major impact on the development of XML for business data exchange in Europe. The European Committee for Standardization (which uses the French acronym CEN ) started a workshop under its Information Society Standardization System ( CEN/ISSS ). The workshop defined several DTDs for generalized transactions as well as those specific to the healthcare industry.[6]

As the XML/edi Group sought to structure and define the vision, the traditional EDI organizations struggled to understand the impact XML would have for them.

Having a common message structure defined in advance makes it possible for software vendors to develop packages that can address multiple industries, and thus spread their development costs over a wider pool of customers.