[Archive copy mirrored from: http://www.geocities.com/WallStreet/Floor/5815/bp01.htm]

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 where attributes identify certain elements as holding EDI information. That way, the EDI information is explicitly labelled, and an XML processor can be asked to return it to an application using standard API calls.

This approach means that the EDI information forms part of the logical structure of the XML document, rather than being a CDATA 'implant'. It also means that users can define their own element types to hold EDI information, so long as they label them with the agreed attributes.

Furthermore, it allows them to use XML's built-in validation facilities to check for structurally valid input, e.g.: in the DTD:

< !ELEMENT N1-GROUP (N101, N102?, N103, N104) >

< !ATTLIST N1-GROUP EDI-TYPE CDATA #FIXED "ANALYSED CONTACT">

< !ELEMENT N101 (#PCDATA) >

< !ATTLIST N101 EDI-TYPE CDATA #FIXED "QUAL PREFIX">

........

in the document:

.........

< N1-GROUP>

< N101>FR< /N101>< N103>1< /N103>< N104>123456< /N104>

< /N1-GROUP>

Note that the EDI-TYPE information is declared once and once only, in the DTD, and does not add to the markup overhead in the actual document.

The above items are just food for 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 35% 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.

Bruce Peat with XML assistance from Richard Light
6/1/97