Issues to Resolve for XML/EDI At least five issues must be resolved for the XML/EDI standard to move forward:

·How do we leverage the work already done on data dictionaries by X12 and EDIFACT?

·How do we identify where an element comes from?

·Is the element from X12 or EDIFACT or an industry group?

·How do we establish data dictionaries that do not currently exist in EDI?

· How do we make the data dictionaries usable to general-purpose electronic commerce applications?

EDI data elements will form most of the electronic-commerce data dictionary--but not all of it. For example, catalog and shopping data often contains more components than one normally needs to generate a purchase order.

A purchase order, for instance, simply may reference the vendor, catalog item number, sizes and colors. In contrast, a catalog listing for that item could have size, colors, cut (full or slim), model number, availability date, discount price and special promotions.

Therefore, shopping data is richer and has more components than ordering data. In general, ordering data specifies an order code, which most likely includes many of the data elements mentioned. The current EDI data elements will solve only part of the problem.

Facilitating E-Commerce Through XML and EDI CommerceNet, an association of more than 500 companies worldwide, along with ASC X12, a major EDI organization, teamed in February to define the existing X12 data dictionary in Internet-friendly XML syntax or semantics. More than 150 XML and EDI experts are involved in the joint project, and some of the issues being explored are syntax language, multiple syntaxes and implementation issues.

· Syntax Language The big question regarding syntax is: What is the best way to use the existing X12 syntax in XML? XML syntax is based on the roman character set and many of the definitions are "English" in nature. For example, an X12 record describing information about the currency used in the exchange is called "cur." Will French or Chinese vendors and buyers be amenable to using English as the basis for naming the XML definitions?

XML supports 32- or 64-bit unicode character sets. So the real issue is not can we represent record tags and data element tags in XML, but should we make the data dictionary language-neutral?

The obvious answer seems to be yes, until you remember that the Internet is based on English syntax. Almost every existing program is coded in English language-friendly computer languages, and--like it or not--the language of international commerce is English. So, the question before the organization is: Should data element tags symbolize things like "cur" for currency or "sjs87" for currency--something that is more language independent?

· Multiple Syntaxes Another issue is whether we even need multiple syntaxes and naming conventions. Suppose we convert the current X12 standard purchase order construct over to XML. We know that , the currency record, is located in a PO, so we know that somehow the record is related to a purchase order. Now, if we use this record tag outside of the PO structure, yet wish to represent currency information for a PO, how do we know that is about currency in the PO process?

For example, you're ordering something from a catalog that asks for the currency in which you intend to pay. If you enter rubles, then it goes into a data element tag data entry slot Rubles, under the record-tag of . Now, without human interpretation in the middle of the data exchange process, how do we know whether this record should be posted against the PO database or against the accounts receivable database?

We may know because of the application that produces the XML pages; but if we move the page's information for input to another database, do we know--in a machine-readable manner--which database record the record should be posted against? Or, should it be posted against both databases since the pair will need the information to process transactions?

<cur>

<currency>Rubles <currency>

<ExchRate> 1 to .5 </ExchRate>

o

o

</cur>

· Standards Implementation Issues What normally happens in the real world is that companies start out using the data format standards, then modify them, a little or a lot, to fit their own needs and those with whom they're communicating. How do we handle the local implementation convention so that it doesn't cause problems to the standards or place undo hardship on those who don't modify the standard date element tag meaning or usage, or type?

Examples of modifications include using 10 characters instead of eight for data element contents and requiring numeric data only instead of allowing for the use of alphanumeric. XML facilitates the means to handle worldwide data format standards and subsequent industry and company-to-company specific modifications to the worldwide standards.

Rik Drummond is CEO of the Drummond Group, an electronic-commerce consultancy, and executive director at CommerceNet. He is also the chairperson for the IETF's EDIover Internet Workgroup and a leader of the Joint CommerceNet/X12 XML Workgroup.

Kay Spearman is a principal consultant for the Drummond Group. She has extensive experience in finance, purchasing, accounting and financial consulting, including 10 years at the director or assistant director level.