The XML/edi Group's XML for E-Business Initiative

November 10, 1999

Alan Kotok and David Webber

Industries and individual companies need to establish standard mechanisms for making XML work for business data exchange. As we have seen with EDI, standards encourage businesses to invest in data exchange technology and help draw in vendors to develop packaged software that supports those standards. The XML/edi Group, among others, have been focusing on key enabling technologies for delivering on such functional XML/EDI standards.

An overview of the first draft of the XML for E-Business recommendations is presented in Table 1, reflecting a series of functions based on business needs. In the rest of this section, we expand on certain key elements of these recommendations: XML repositories and Bizcodes. We then look at the importance of maintainability and scalability in XML/EDI applications.

Table 1: XML/edi Group's XML for E-Business Recommendations

XML Repositories Store the E-Business Valuables

Once XML vocabularies have been developed for the data elements exchanged in business processes, there is a need to have them available for use. This is the function performed by a repository. Data definitions are stored in the repository for retrieval and use by e-business applications. In particular, a network of relationships between data definitions is built up, with the re-use of element definitions from other industries, and the establishment of data elements between which there is an effective equivalence.

We propose that to document these relationships, repositories rely on semantically neutral references called "Bizcodes". Just like the familiar UPC/EAN bar codes for products and items that provide simple semantically neutral numbers for manufacturers, distributors, and retailers to use for inventory control, Bizcodes provide neutral identifiers for relating data elements among electronic transactions and across industries.

For example, a party that engages a company to acquire goods or services could be called a customer, client, guest, buyer, renter, visitor, or user depending on the industry. XML vocabularies for these industries would identify these entities using the terms most familiar to those industries: <CustomerNr>, or <ClientNr> or <BuyerID>, and so on. Each industry may use its own vocabulary (with different terms and tag names) but they all essentially reference the same thing.

Traditional EDI has addressed this consideration with code and element dictionaries, but has not provided the roadmap for the cross-referencing. Instead, individual EDI tool vendors have provided their own industry specific vocabularies mapped to the standards.

In XML parlance, this integration of the terms, and the data model along with the business use semantics, is known as a schema. So a vocabulary combined with data structures and business rules can be expressed in XML syntax using schema definition rules. In the XML 1.0 specification the schema modeling tools are known as the Document Type Definition (DTD) syntax. The W3C's draft XML-Schema specification will extend the modeling capability far beyond what is currently possible with DTDs.

In the XML repository for each of our example industries, a glossary would equate a specific identifier to the equivalent Bizcode. An industry could create a label for the Customer/Client/Buyer identifier example and call it "BE000123". A company from another line of business that needs to interact with companies using that industry's XML vocabulary could precisely relate its customer or buyer or client identifiers to BE000123.

As a result, trading partners in a vertical industry can use the business terms and rules with which they are familiar, yet still relate to allied businesses. In the financial world, stock brokerage houses can relate to personal banking integrators and to financial regulators, where each group uses related information that overlaps across the business domains. Financial industry associations through their XML syntax working groups are already looking into these ways of interacting.

Another important use of Bizcodes is to locate, re-use and transform information (often called mapping) both within business transactions and more broadly across the web itself. An example is product catalogues. A vendor may have a catalogue displayed on the web using its own vocabulary, such as <ProdCode>, <Cat>, <InStockQty>, <Delivery>, <Product>, <ListPrice>, <WebDisc> and <TechSpecs>. From their published Bizcode references (these can be conveniently documented in an XML DTD), software can then automatically relate these references to a search process that locates customers for specific products.

In a global economy, Bizcodes can also provide an effective method of translating between languages. A customer in Japan, for example, could see search results displayed in their own language; replacing the original English terms. Notice in this context that Bizcodes can work more robustly and directly than traditional vocabulary labelling techniques, or mapping the vocabulary itself, where any variance in the spelling or naming will cause significant failures to occur.

Technically, Bizcodes are implemented using fixed attributes in DTDs. More information on repositories and Bizcodes is available in the XML/edi group's XML Repositories white paper. Note that Bizcodes are here introduced as the "ATTLIST mechanism".

Data Exchanges Must Be Scalable and Maintainable

At the beginning of this article we saw how IDC are predicting a major upsurge in business use of XML and the Internet. To successfully expand traditional EDI style systems to a global audience of tens of thousands of trading partners means developing and deploying new, innovative, and very robust software processes. Simple arithmetic is at work here. If your current EDI department processes 50,000 transactions daily, working with 200 trading partners, will that support group be able handle ten times that number of partners? Would you, or could you, hire more people to accommodate that volume?

Clearly the new breed of XML/edi systems must be flexible, and able to handle a large expansion of exchanges without excessive human interaction. This is why there is a need to understand how we can integrate software agent technologies into XML/edi systems.

Up to now, the picture seems discouraging. Despite the grim lessons of Y2K compliance that have cost businesses billions of dollars, many software development teams are still happily creating hard-coded systems with ready-made limits on their ability to handle new and different business data.

We are not talking about highly advanced capabilities here, but simple measures like avoiding creating an information system that will only handle 2 address lines in an address, or no more than 10 items per order, and so on. What happens when an order with 11 items, or 3 address lines comes in?

XML provides the means to express metadata without specifying hard-coded constraints. This means that developers building new XML implementations should avoid hard-coded constraints in the XML content to prevent such problems in process models.

Creating XML software systems that are significantly flexible, fault tolerant and scalable is a design and engineering challenge. Software agents can help this process. The most immediate need is for tools that can track XML transaction content and alert support staff to potential failure conditions in the information, particularly relating to versioning. Traditional EDI implementors have long understood the need to manage versioning between trading partners. In an XML-driven world, such changes are exacerbated by the ease that trading partners can change and revise the details in their transaction content and structures.

XML for E-Business: A Growing Concern

In addition to the work being pursued by the XML/edi Group, other groups are recognizing similar needs and requirements. Among initiatives in this are CommerceNet's eCo Framework and the ebXML initiative launched by the United Nations' CEFACT and OASIS.

The inaugural ebXML initiative meeting takes place this November. The stated objectives of the ebXML initiative closely mirror those envisioned in the XML for E-Business Initiative. What may differentiate the two is in that the former has a higher level, top-down approach, while in the XML/edi Group's work there is a detail-oriented bottom-up approach. As such, both approaches are complementary.

Further Thoughts and Review

The W3C and other bodies must recognize the needs of doing business with XML when crafting further refinements to the XML standard. They must ensure that the emerging complexity found in extended portions of new working drafts on XML technologies does not derail the process of providing simple, consistent, light weight, easy-to-learn and broadly maintainable e-business systems.

Michael Swaine, editor-at-large for Dr. Dobb's Journal, in his November 1999 DDJ column "Programming Paradigms", puts all this very succinctly while discussing the Oxygen Project at MIT (introduced on MIT's site in this transcript). Under the heading of Attaining Invisibility, Swaine writes: "The goal of MIT's Oxygen Project is to push computer technology and information technology beyond what passes for ease-of-use today, making it not only accessible to everyone, but richly exploitable by everyone".

Swaine then identifies the key technologies that will deliver on this promise. "The five technologies of speech (and other perceptual capabilities), knowledge access, automation, collaboration and customization are the only new kids on the block. Out of the thousands of things that we can imagine doing in the new world of information, these five are the foundations on which any new activities that help us do more by doing less will be built".

Doing more by doing less—this mantra is central to the vision for XML/edi. Realizing e-business is an early step towards a world of transparent computing envisioned by the MIT project.

Much work in e-business remains to be done: XML repositories coupled with Bizcodes by themselves cannot capture all the aspects of automating a data integration process. When an application system transforms and re-uses information across domains, both structural and business semantic changes occur, and software may also re-combine data to produce new data.

However, our objective here has been to introduce the core concepts behind the XML/edi Group Initiative on XML for E-Business, and show how these aspects are critical for implementing broad-based global electronic commerce via the Internet.