xml-dev - A few thoughts on XML and EDI

["Peat" <peat@erols.com>]

XML/EDI
Advantages of including Electronic Data Interchange (EDI)
entities with eXtensible Markup Language (XML)


The advantages of including Electronic Data Interchange (EDI) entities with
eXtensible Markup Language (XML) differs for each camp.  

-- For the EDI camp the unification means making application implementation
easier, allowing for quicker reach into vertical markets, reduced message
stores when processing transactions, and most importantly enabling
document-centric tools such as search engines and Internet "push" products
to supplement database mechanisms.  

-- By assuring EDI compatibility, the XML camp gains almost instance use
among thousands of companies.  XML will gain a common extensible data
entity definition which has under gone the test of time. 

The bottom line:  the XML camp gains Fortune 1000 support and the EDI camp
gains a common presentation protocol. 


If the combination can bring this much to the table why hasn't it been done
before now?

The attempt to combine structured presentation with structured data for
transactions is not new.  The last attempt ended a little over a year ago. 
At that time the researchers of the Joint Electronic Document Interchange
(JEDI) project which were managed through the Division of Learning
Development Research Group at De Monfort University Leicester, the Computer
Science at University College London, and the Document Interchange project
at UKERNA completed their study.  The project's intent was to analyze the
current international and industry de facto standards that are in use for
electronic document creation, transfer and presentation. The project was to
identify the set of common elements that would allow the conversion of both
logical and layout aspects of a document. The documents would then be
viewed using a WWW type browser that was available for common computer
platforms.  The JEDI project concluded that SGML is ideally suited for EDI
as it is text based and is independent of platform and operating system.
The actual results were a little disappointing in that the world was and is
still not ready for an SGML/DSSSL implementation.


What has changed, for us to try again?

It is a year later, and in the Internet timeframe this is plenty for
momentum to shift.  Due for release sometime this summer is an important
specification to WWW browser-based applications - the eXtensible Markup
Language (XML).  The intent is to make the rather rich HTTP protocol even
richer.  It is a scaled down simpler version of SGML, in fact the one of
the goals of the specification is to  "...be straightforwardly usable over
the Internet."  The key here is "straightforwardly usable."  This flavor in
the design of XML which is why the specification will succeed for
transactions where the SGML/DSSSL failed.  This is not to say that
SGML/DSSSL wouldn't work, but more a reflection on us accepting change. 
Change sometimes needs to be taken in a series of steps - XML is the next
step.


What about the momentum with XML?

XML, managed by the World Wide Web Consortium (W3C) working group, will no
doubt become the next significant enabling technology for the Web. XML will
provide Web publishers and consumers  with unprecedented power, flexibility
and control over the creation of and access to Internet and intranet
content. To date the XML specification is backed by SoftQuad, Adobe, IBM,
HP, Microsoft, Netscape, Lockheed Martin, NCSA, Novell, Sun, Boston
University, Oxford University, and the Universities of Illinois and
Waterloo. In addition to the authors of the specification, about 30
companies already support the CDF; Channel Definition Format, an XML
application which brings to the Internet various "push" operations. 
Netscape and Microsoft and have already pledged XML support in their future
WWW browser releases.  And many corporations are being added to the list as
they learn of the specification's existence and capability.  


What could the EDI entities look like?

The general format of the transaction would be described in HTML.  The EDI
segments and elements could go something like this...
....
DUNS Number:
<![CDATA[<N101>FR</N101><N103>1</N103><N104>123456</N104>]]>

… <or>

DUNS Number:
<![CDATA[<N1>FR*1*123456</N1>]]>


The above items are just a thought.  Hopefully, when both camps view the
above lines, they see only a slight modification to the methods implemented
today.  To include the right hooks, CDATA or other XML entities might have
to include some specific syntax for EDI.  The details, though not many, can
be ironed out by the excellent authors of both camps.


So then XML documents are really just EDI templates, Right?

Yes and no.  Yes the documents can be used as templates.  But in addition
to this application, 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.  Combined effort in template
or application form creation and development is estimated in the thousands
of man-years, not hundreds.  Soon there will be a standard 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. 

In addition to templates, and transactions, tools are available today to
store, search, route, narrowcast and maintain information in document-form.
By adding defined data entities, these tools can be enhanced to make EDI
processing and integration much easier.  Database, EDI specific, and
application programming tools were for the longest time the only choices,
the only options for EDI administrators.  XML/EDI will give the EDI
administrator more choices.


If presentation elements are included in the transaction what happens to
our transmission bandwidth? 

The transaction would certainly require more bandwidth as compared to EDI
specification today.  The additional strain on a corporation's
infrastructure must be weighed with those advantages gained by the use of
XML/EDI on a case by case basis.  It is estimated that the XML/EDI-based
transactions would add about 15% to the size of the current transactions. 
In the cases where this increase is significant, the XML/EDI standard
documents can replace proprietary templates, which would still allow for
use of document-based tools internal to the organization. 


Where do we go from here?

- Introduction of the two camps - XML and EDI
- Education of both camps of the others existence, tools and implementation
methods
- Assure that the proper hooks are in XML to support EDI
- Create an EDI application for the Extensible Markup Language (XML)
- EDI "mappers" must add XML parsing to their front-end logic.



Please reference…
Joint Electronic Document Interchange (JEDI)
http://www.sil.org/sgml/gen-apps.html#jedi



EC/EDI References… 
Electronic Commerce Resource Center http://www.ecrc.ctc.com
EC/EDI Jumpstation http://www.premenos.com/Resources/Organization
Overview of EC can be found at http://www.dmx.com
Listing EC sites: http://planetx.bloomu.edu/~jsdutt/EC-urls.html

Mailing list devoted to issues of EDI:  To subscribe to the list, called
EDI-L, send an Email message to  listserv@uccvma.ucop.edu with the line 

subscribe edi-l firstname lastname 

(l for List, not numeric 1) in the message area; To send a message to the
mail list, address messages to edi-l@uccvma.ucop.edu



XML References…
XML Press Release (SoftQuad) http://www.sq.com/press/releases/prmar1197.htm
The XML W3C Working Draft is at
http://www.w3.org/pub/WWW/TR/WD-xml-961114.html
eXtensible Markup Language Site http://www.jtauber.com/xml/
Channel Definition Format application for XML
http://www.microsoft.com/standards/cdf.htm

Mailing list devoted to issues of XML: To subscribe to the list, called
XML-DEV, send an Email message to majordomo@ic.ac.uk with the line 

subscribe xml-dev name@address

(where name@address is your actual email address) in the body of the
message. To send a message to the mail list, address messages to
xml-dev@ic.ac.uk



Bruce Peat
peat@erols.com


xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)