Electronic commerce isn't new - more than 300,000 of the largest companies worldwide exchange electronic trade documents every day. XML-based Internet commerce can't simply ignore this realm. According to Munro's Law, "The value of an e-commerce solution is exponentially proportional to the number of companies that use it."
If we apply this rule, EDI (electronic data interchange) dwarfs the entire combined volume of XML e-commerce - which is why a viable XML-EDI solution is critical to the success of XML e-commerce as a whole.
This column will discuss XEDI, an approach to representing EDI in XML syntax. In this issue I'll provide what I hope will be a compelling introduction to XEDI. In subsequent issues I'll provide more details on EDI and programming with XEDI.
When the XEDI working group began looking at the problem of EDI to XML, we quickly realized that the challenge was a many-to-many translation (see Figure 1).
There were already many types of EDI. Not only were there two distinct houses called X12 and EDIFACT, but also different release versions of each - and even different industry subsets. There were also many different XML specifications: RosettaNet, cXML, CBL, X12c, OAG and ECO all had different proposed XML representations of trade documents.
The most common approach to solving a many-to-many problem is to break it into two smaller problems: a many-to-one problem and a one-to-many problem. This is the approach the XEDI working group adopted. To solve the XML-EDI challenge we needed a common intermediate step that was also as simple as possible. The result was XEDI.
The Direct Approach
Numerous groups were working on the XML-EDI problem long before the XEDI working group - the ad hoc XML-EDI Group, the X12C Committee, CommerceNet, the SGML Centre and ISIS, to name a few.
Each of the groups took a broadly similar approach: they made a DTD for each business document or transaction set and made elements out of the human-readable metadata. We call this process the direct approach.
It turns out that this approach was actually the hard way to go. Every group that tried it needed to create every transaction set from scratch. As a result, these groups, even after 18 months of effort, still have only a handful (perhaps 10) of transaction sets completed. XEDI on the other hand now has every transaction set complete in every version of X12 and EDIFACT.
The direct approach creates several problems. It requires a different DTD for every transaction set, which means hundreds of DTDs. It requires a different XML element for every EDI segment and element, which means hundreds of element definitions in every DTD. And it uses the human-readable metadata as the element name, which makes for some very long and unwieldy tag names such as:
More important, these tag names are the English versions of the human-readable metadata. By using these versions as the tag name, the direct approach enforces a U.S.-centric DTD - not a viable approach in a global economy.
The direct approach also doesn't address how to incorporate the machine-readable metadata that EDI already has. Most implementations of this approach have dropped the machine-readable metadata altogether. Others have appended the machine code to the tag name, a feature that the document object model (DOM) wasn't designed to support.
The direct approach, overall, leads to a very cumbersome solution.
The Indirect Approach
In contrast, the XEDI working group took an indirect approach. We were designing a DTD that was an intermediate step of a many-to-many translation. In its initially intended use, no one but a handful of developers would ever really see a XEDI document. This freed the XEDI working group to adopt a novel approach - one that turned out to be simpler.
The XEDI DTD is the metamodel of an EDI document. The tags are for transaction set, segment, element, name and value. The same DTD is used by all EDI documents. The XEDI documents are nevertheless self-describing. All the human-readable metadata is stored in the contents of a name element. The machine-readable metadata is stored as an attribute of the elements.
Rather than the DTD, another more manageable set of documents - called the data dictionary - describes the hundreds of transaction sets, segments and elements in EDI. The data dictionary files are XML.
The following is the beginning segment of a typical X12 850 purchase order. Can you find the purchase order number in it?
An EDI document is simply a series of segments of this sort. The fundamental shortcoming of EDI is that all the human-readable metadata has been stripped away in order to make the documents as compact as possible. The same segment is shown in Figure 2. The XEDI working group believed that the primary advantage XML could bring to EDI was the reinserting of the human-readable metadata.
The best way to explain XEDI's indirect approach is for me to walk you through the translation of this EDI segment into XEDI:
1. The characters before the first asterisk specify the segment type. Open the BEG.xml file from the data dictionary for this trading partner. We'll assume that the trading partner uses the standard X12 version 4010, which can be found at www.xedi.org/X12/en/4010/segment/BEG.xml.
2. The BEG file specifies the name of this segment. We can generate the following XEDI output that contains the machine-readable metadata as an attribute and the human-readable metadata as the contents of a name element:
<name>Beginning Segment for Purchase Order</name>
3. The BEG file specifies that the first element is a 353 transaction set purpose code. You'll see the following line in the data dictionary source:
<elementRef code="353" req="M" href="353.xml">
Transaction Set Purpose Code</elementRef>
4. Open the 353.xml to learn what 00 means. EDI is rife with two-digit codes that stand for some business meaning. We find the following line in the 353.xml file:
5. We can now enter our first element into the XEDI document, shown in Listing 1. The tags describe the metamodel, the attributes contain the machine-readable metadata and the name elements contain the human-readable metadata.
6. According to the BEG file, the second element is a 92. We look in file 92.xml and look up the meaning of "SA." The process works as before and our result is shown in Listing 2.
7. The third element is a 324 purchase order number, but notice that the BEG file has an "element" tag here instead of an "elementRef" tag - indicating that this element doesn't contain two-digit codes for its value. The content of the EDI document is the value.
<element code="324" req="M">Purchase Order Number
8. The result is shown in Listing 3.
9. The EDI source now has an **, which indicates an empty element. We can insert an empty element or we can insert an element with an empty value.
10. The rest of the elements follow the procedures already described.
11. Notice that the BEG file lists 12 different elements, but the EDI file contains only six. The remaining nonexisting elements are interpreted as being empty. Thus our final result for the segment is as shown in Listing 4.
According to the initial intent of XEDI, no one would ever really see an XEDI document - it was just an intermediate format. EDI would turn into XEDI and then immediately turn into some other XML form such as RosettaNet or cXML.
The XEDI working group stuck to this approach by creating an XSLT stylesheet that transformed XEDI into cXML. We found, though, that in the process we were throwing out a good deal of the information that existed in the XEDI document. The reason was obvious - the semantics of EDI have matured over 20 years, and RosettaNet, cXML and the others simply haven't had the opportunity to mature.
The XEDI working group believes that in time XML-based trading standards will meet and eventually exceed existing EDI standards. We believe that this could happen as quickly as in the next 18-36 months. At that point XEDI can easily map to these standards and serve as the intermediate format it was designed to be. In the meantime XEDI provides companies with the ability to expand their existing EDI trading systems today using XML.
XEDI serves as an intermediate step in an evolution of electronic commerce. It doesn't try to achieve all desirable characteristics such as object-oriented EDI or business-process EDI. It does, however, provide a significant and immediate step forward toward these objectives. It's in this spirit that the X12 SITG committee has called XEDI "Step Zero."
In the space available to me I've tried to provide as detailed and compelling an introduction to XEDI as possible. It's a wide field to cover and I've had to make various assumptions about the background and knowledge possessed by readers. In coming issues I'll discuss in more detail how XEDI applications work and how you integrate applications using XEDI. You're welcome to suggest questions and issues you'd like me to deal with.
X12C Committee: www.x12.org
XML-EDI group: www.xmledi.org
SGML Centre: www.sgml.u-net.com/
Open Application Group (OAG): www.openapplication.org
© 2008 SYS-CON Media Inc.