Technology and Society - Electronic Commerce

Business Data Interchange

XML meets EDI

Status of this document:

This document is still at a early stage and does not raise claim to completely cover this topic.
Please contribute feedback to the author pierre.kerchner@w3.org or W3C member mailing list www-xml-edi@w3.org (subscribe with mail to www-xml-edi-request@w3.org and subject:subscribe).

Abstract:

Reaching the best of two worlds is always a promising challenge, particular in this case, where XML and Electronic Data Interchange, todays most widespread Electronic Commerce application, meet. Both architectures have their individual background, history, advantages and disadvantages. The purpose of this paper is to contrast these two technologies, appreciating their nature to initiate a discussion where additional technologies are needed, based on the assumption that there is high interest among the W3C in further evaluation of XML as a data format for business purposes.

Merging the best out from 2 different worlds - combining existing technologies towards something new and superior. This can be a vision for the XML and Electronic Data Interchange (EDI), today's widest spread Electronic Commerce application. Both architectures have their individual background, history, advantages and disadvantages. A crossover could bring much benefit to the world of commerce as well as to the WWW and Internet. This paper shall give a brief analysis of strengths, weaknesses, opportunities and threats. Furthermore it is intended to raise discussion and evaluate resonance on this topic. There are profound assumptions that there is a high interest among the W3C members and XML&EDI will have it's impact.

Why Business Data Interchange?

Internet standards are getting the common denominator for open and global information exchange. HTML and the WWW, important and central parts of today's Internet, are evolving towards the next stage: the eXtensible Markup Language. One big strength of is XML is to supply explicit semantic through flexible markup.
This architecture would also reasonably improve Electronic Commerce. The gain on efficiency describing and exchanging business transactions electronically is enormous - decreasing cost, increasing service, speed and quality (e.g. see Michael Hammer, Business Process Reingineering) but also open completely new possibilities on information usage. Existing commerce applications like traditional Electronic Data Interchange (Trad-EDI) lack of integrated processes and interoperability - the WWW and Meta Data fill these gaps.

Some members of the W3C might acknowledge this coherence and are therefore very interested that XML is not only used as document format but additionally also as data format describing e.g. business data.

Problems of Existing Approaches

Old and existing standards like EDIFACT or ANSI X12 have grown during the last 25 years. At a time when storage and bandwidth were very expensive, many different Trad-EDI standards evolved through multilateral agreements and long standardization processes. The document architecture is very condensed and tense through high context sensitivity and code qualifiers. This results in a very compact message format, but which is not very easily parsed and processed. Furthermore the architecture is not designed towards modularity and extensibility (transport layer, syntax and semantics are merged)

Nevertheless there are many proprietary and non-compatible subsets due to the wish for total and global approach defining also quite uncommon business cases (industry solutions). This soon turned out as complexity trap. Standards got too complex, deployment costs to high to be attractive for small and medium sized companies. Despite that about 100,000 companies adopted a Trad-EDI standard during the last 25 years (95% of Fortune 1000 use Trad-EDI).

Today's world changed - there is different infrastructure and consequently different requirements appear. Processing power, storage and bandwidth are relatively cheap. Globalization of markets and information is emerging. Complexity on the other hand leads to high implementation costs which avoids wide spreading or global deployment, because high qualified manpower is still very expensive.

EDIFACT EANCOM-Invoice example:

UNB+UNOC:3+"ILN-Sender":14+"ILN-Receiver":14+970303:
1316+00000000000002+++++EANCOM+1'UNH+00000000000001+
INVOIC:D:93A:UN:EAN007'BGM+380::9+00186792+9'DTM+137
:19970221:102'ALI+DE++8'NAD+IV+"ILN-Invoicee"::9'NAD
+BY+"ILN-Buyer"::9'RFF+API:567890'NAD+SU+"ILN-Suppli
er"::9'RFF+API:876543'NAD+II+"ILN-Issuer"::9'NAD+OB'
RFF+API:"Customer-No"'CUX+2:DEM:4'PAT+3'DTM+209:1997
0321:102'UNS+S'MOA+86:8357.56'MOA+125:7267.44'MOA+17
6:1090.12'UNT+20 +00000000000001'UNZ+1+0000000000000
2'

Fields of Improvement/Advantages of Meta Data 

"Opportunities"

• XML - a basis for self-describing documents - human and machine readable - (semantic potentially included)
  
  fictitious example:
  

  <?xml version="1.0"?>
  <Order>
          <SoldTo>
                  <LastName>Berners-Lee</LastName>
                  <FirstName>Tim</FirstName>
          <SoldTo>
          <SoldOn>1998-10-15<SoldOn>
          <Item Description="The History of W3C"/>
          <Item Quantity="3"/>
          <Price Currency="USD">1.91</Price>
  </Order>

  
  

• Basic XML features: modularity - extensibility - scalability (fragmented documents) - please refere to XML-spezifications

• Flexibility - Namespace is equal to a shared semantic space. They allow to focus on different levels of complexity
  (on transaction by transaction, partner by partner, industry by industry or on a global basis).
  
  fictitious example:
  

  <EDIFACT:EDIFACT xmlns:EDIFACT="http://www.unece.org/EDIFACT/">
  ...       
          <EDIFACT:D96B:INVOIC .... />
  ...

  
  This brings complexity away from the standard definition towards "ad hoc real-life" business. The "100% automation" paradigm could be given up for individualized and flexible business transaction consciously involving human interaction.
  

• Document Type Declaration (DTD) proof document structure - easy to parse - easy to validate syntax - please refer to XML-DTD

• Universal Resource Identifier (URI) - concept:
  
  fictitious examples:
  

  http://inhouse.mycompany.com/invoice/1998/10/443636.xml
  http://inhouse.mycompany.com/invoice/myinvoice.dtd
  

  Data consequently is not moved - only link (references) are sent - modifing or updating does not result in outdated documents.
  Universal keys (cp. RDBM) for any document or schema can easily be designed. Information is always accessable from the same location.
  
  This concept could have two different gigantic impacts:
  
  -document instance: e.g. individual business documents could be transferred by just submitting the URI not the whole message
  -document schema: descriptions, DTDs, schemes etc. can be externally referenced.
  

• No distinction between business-to-business model and business-to-customer model -> one world - one model (markup engines as client)

• Platform independent (accessible, internationalized by UNICODE)

Tradeoffs/Threats:

• Overhead - verbose format (but today storage and bandwidth are relatively cheap)
• not proofed yet - new standard (but only new combination of existing technologies)
• stronghold of Trad-EDI at some industries -> migration/integration strategy is vital
• Threat of Babylonian amount of DTDs/Schemas

Issues:

• Right balance between openness and standardization - pasted Important is the right balance between flexibility, complexity, power and ease of deployment and implementation.
• What kind of approach: incremental improvement vs. hard cut & design of a new EDI next generation?
• 1:1 mapping from existing standards to XML/edi - soft migration?
• Nevertheless standards and agreements are absolutely necessary

Roles of new W3C-Technologies

XML (eXtensible Markup Language)

• basic document & DATA description format
• examples
• syntax layer -> modularizes
• syntax layer -> nice parsing properties (wellformed, fragmentable, cheap software modules etc.)

RDF (Resource Description Framework)

• the glue - describing resources & interrelations - modeling
  
  fictitious example:

  ...
  <rdf:RDF>
          <rdf:Description about="http://mycompany.com/">
                  <edi-rdf:EDItype>UN/EDIFACT d96b</edi-rdf:EDItype>
          </rdf:Description>
  </rdf:RDF>

  
  
  "external" description of resources e.g. data elements, messages, dictionaries, repositories,  standards, ...

• decentralized repositories - distributed architecture
• provide information to "translate" from one BDI schema to another: machine-understandable descriptions of schemas
• easy to update and adapt to changing necessities
• RDF is in XML-Syntax

XSL (eXtensible Style Language)

• mapping and translation function
• self containing (processing) code
• ECMA script included

DOM (Document Object Model)

• the API - the glue to external tools: one part of the solution to Babylonian schemas (?)

XFDL (eXtensible Form Description Language) = external submission

• GUI for signed forms
• ties answer to question
• Authentication and integrity

Questions and Goals:

Questions:

• data typing, business schemes, structures for repositories
• requirements for RDF, XSL, XML namespaces, new XML Working Groups (schemas, fragments etc.)
• how to use these elements together ?
• transition from existing standards - converter

Goals:

• defined process for standardization to avoid technology lock-ins
• tracking of dependencies with other groups
• balance between standardization and flexibility
• good symbiosis of supplement and replacement of existing standards

Important EDI key players - Existing Standards

• UN/EDIFACT (United Nations Electronic Data Interchange for Administration, Commerce and Transport, international standard with subsets EAN, EDIFICE, ODETTE)
• ANSI X12 (US Standard with subsets X12A, X12C,X12E,...)
• SEDAS (European consumer goods)
• TRADACOMS (UK standard)
• VDA (German car manufactures)
• SWIFT (International banking)
• IDOC (SAP-to-SAP INHOUSE)
• HL7 (Health)
• open edi ISO/IEC 14662
• oo edi

Key Players:

Copyright  ©  1998 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.