The
XML/EDI group's
website provides a number of related papers.[Archive copy mirrored from: http://www.pira.co.uk/IE/top032.htm]
Top | News archive | Projects | Products | Topics | Events | Resource Links and downloads | Site info | Search | Feedback |
A posting to the XML developers list suggests a number of potential advantages of closer cooperation between the developers in the field of Electronic Data Interchange (EDI) and those developing eXtensible Markup Language (XML). For the EDI camp the unification could mean making application implementation easier, allowing for:
In return by assuring EDI compatibility, the XML camp could gain almost instant use among thousands of companies. XML will gain a common extensible data entity definition which has undergone the test of time. The bottom line being that: the XML camp potentially gains Fortune 1000 support and the EDI camp gains a common presentation protocol.
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 Department at University College London, and the Document Interchange project at UKERNA completed their study.
The project's intent was to analyse 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 Web 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 it seemed that the EDI world was, and is still not ready for widespread SGML/DSSSL implementations.
It is a year later, and in the Internet time-frame 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). As a scaled down, simpler, version of SGML, it has the stated goal of being "...straightforwardly usable over the Internet".
This particular design goal of XML is likely to ensure that the specification will succeed for transactions where SGML/DSSSL failed. This is not to say that SGML/DSSSL wouldn't work, but is more a reflection on developers accepting change. Change sometimes needs to be taken in a series of steps - XML seems to be the next step.
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.
The general format of the transaction would be described in HTML. Hopefully, only a slight modification will be necessary 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.
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 from which to share the work others have done, applications need only to simply access Web browser objects. This object-based approach to applications will make document transaction exchange even easier. The bottom line being that 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.
The transaction would certainly require more bandwidth as compared with the current EDI specification. The additional strain on a corporation's infrastructure must be weighed against 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 the use of document-based tools internal to the organization.
There are a number of steps which are desirable in order to to bring about EDI/XML, these could include:
This posting was made by Bruce Peat (peat@erols.com) to the mailing list devoted to issues of EDI called EDI-L. To subscribe to the list mailto: listserv@uccvma.ucop.edu with the line subscribe edi-l firstname lastname.
The
XML/EDI group's
website provides a number of related papers.
Return to Electronic Commerce topic page
Return to Interoperability & Standards topic page
We welcome feedback and contributions to the information service and discussion on the concept and scope of Information Engineering, e-mail to ieserve@Ketlux.demon.co.uk.
Last up-dated July 10th, 1997