5 June 1998 CEFACT AD HOC WORKING GROUP ON SIMPL-EDI AND FORMS AND WEB BASED EDI (SIMAC) Proposal for a UN Repository for XML/EDI SOURCE: Dick Raman STATUS: CONTRIBUTION ACTION: FOR DISCUSSION
page 2. Dick Raman Chairman, EEMA EDI Work Group, Head of EEMA delegation in CEFACT, President, EDI-TIE BV PO Box 538 2130 AM HOOFDDORP The Netherlands Telephone: +31-23-5639971 Fax: + 31-23-5641748 E-Mail info@edi-tie.com EEMA EDI Work Group Proposal for a UN.......... Repository for XML/EDI
page 3 Proposal for a UN Repository for XML/EDI Introduction The EEMA EDI Work Group would like to propose to CEFACT the establishment of a Global Repository for the translation of XML tags in UN/EDIFACT and human language on the Internet. The EEMA EDI Working Group is prepared to assist in the set up and operation of such a repository, which could be crucial in the advancement of the use of EDI over the Internet. Background The XML/EDI group was founded in the USA in July 1997. It was set up in response to President Clinton s call for industry supporting dealing with Internet based commerce issues. The XML/EDI group is an ad-hoc group of professionals and volunteers from various industries, dedicated to promoting and guiding the future of XML/EDI products and a standard by donating their time and energy. The group s mission is to promote and develop a set of Guidelines and to promote the adoption of those Guidelines within the traditional standards bodies for Electronic Business and with commercial software developers. Membership of the group is open to anyone with an interest in improving Electronic Commerce for end users and specifically through the use of XML and EDI together. Furthermore the group tries to provide Internet based resources for people involved in XML/EDI, to develop a set of guidelines and to provide, through a number of focused groups, a wide adoption of XML/EDI throughout the business world. The group aims to develop public domain tools and open systems software whenever possible, so anyone who would like to use XML/EDI can do so free of charge. The philosophy behind the group s initiatives is that they think that XML/EDI, as a business tool, will reach a very large audience. Technical XML stands for extensible Markup Language and as such it is a subset of SGML (Standardized General Markup Language), which is also the mother of HTML. XML/EDI is the fusion of five technologies. It is that which makes XML/EDI so powerful. These technologies are: XML, EDI, templates, agents and repository. These components all work together to create an XML framework for business use. In terms of complexity XML can be placed between SGML and HTML. It uses the SGML syntax to transport components across the network. The XML tags can actually replace existing EDI segments or data-element identifiers, which produces a somewhat bigger file than an EDI file, but in which all the labels of the data-elements (in other words the descriptions or explanations) are included as well. The templates are essentially rules that determine how the XML files should be interpreted. It can define the layout of the file and is supplemented by DTDs (Document Type Definitions) that enable transaction operability. The agents can interpret the templates to perform whatever job needs to be done, but they can also interact with the transaction and help the user to create new templates for each specific task. The repository is a location where shared Internet directories are stored and where users can manually or automatically look up the meaning and definition of XML/EDI Tags. The repository is in fact the semantic foundation for the business transactions. What makes XML/EDI different from previous initiatives, is that its aim is to use the know-how of business processes, captured in EDI messages, but tries to put it in a Web environment, whereby the same file can be viewed by a user or can be processed by an application. Rather than having HTML for a user and EDIFACT for an application, with XML/EDI you can have an EDI message that can be an EDIFACT orders message written in an XML format; therefore it is presentable to the application just like the EDI file. The
page 4 same file uses the embedded templates and rules that explain how it should be displayed to a user and can be viewed through a browser. Why is XML/EDI so useful? One of the weaknesses of EDI was always that it was quite invisible and it actually only worked well when it was application-to-application. For a long time we have created dummy applications that would allow the user to view the contents of an EDI message or create the contents of an EDI message. This would then be translated and sent out as an EDI message, so that the (usually bigger) partner would receive EDI. With XML/EDI this becomes a lot easier. The idea behind the whole initiative is that in terms of a workflow application, one can send an EDI message in an XML format to a supplier who can then pick it up and present it through a browser to a person who is in charge of approving incoming orders. That person can add some data to the incoming order, which actually signals his approval - this could for instance be a digital signature. The approved order can then be sent into the supplier s application as a plain EDI file. In this way, as a human or an application creates a message it can travel through an organization, and can be sent to another organization and switch between humans and applications also. Every time the XML file will become larger, containing new updated information and as such it is almost a foundation for a workflow application. As far as the general idea behind XML/EDI is concerned, this is quite exciting. It is obvious that the syntax of EDIFACT is outdated. The objections to wrapping an EDI message in an XML format is that a lot of overhead is created in the message. Below is an example of what an XML/EDI message might look like: <!DOCTYPE order SYSTEM "http://www.myco.org/messages/xml/message1.xml" [ <!ENTITY % items " <!ELEMENT item (item:identifier, item:name, item:quantity)> <!ELEMENT item:identifier (item:database-key?, item:ean) > <!ELEMENT item:database-key %data; > <!ELEMENT item:ean %data; > <!ELEMENT item:name %data; > <!ELEMENT item:quantity %data; > "> ]> <order> <order-no>123456</order-no> <deliver-to> <address id="sgml154"> <address:company>the SGML Centre</address:company> <address:street>29 Oldbury Orchard</address:street> <address:town>churchdown</address:town> <address:region>glos.</address:region> <address:postcode>gl3 2PU</address:postcode> </address></deliver-to> <invoice-to> <same-as idref="smgl154"/> </invoice-to> <item><item:identifier> <item:database-key>key151235</item:database-key> <item:ean>15356378797</item:ean></item:identifier> <item:name>special Offer 16</item:name> <item:quantity>12</item:quantity></item></order> As you can see all the tags, which are quite lengthy, have to be closed by the same tag with a slash in front, which creates a lot of overhead. At this point the XML/EDI group is still studying how to define the syntax. It is in the process of making proposals to the W3C to get the standard approved. Proposal to CEFACT To many people XML/EDI is also what they call a politically correct way to merge ANSI X12 (the US standard) and EDIFACT (the world standard). As a US initiative
page 5 XML/EDI is strongly supported by the DISA (Data Interchange Standards Organization), the governor for the ANSI standard and also the secretariat for the Pan-American EDIFACT board. As such the DISA is promoting strongly and investing money into the advancement of XML/EDI. As a fusion between ANSI X12 and EDIFACT XML/EDI could have a great future. From a worldwide point of view this would only work if XML/EDI was supported by the UN. To that effect the EEMA EDI Working Group is submitting this proposal to see that a study gets underway to examine whether the EDIFACT standard could merge with the ANSI standard in an XML/EDI environment. This could work, because from a technical point of view the ANSI 850 orders message and the corresponding EDIFACT ORDERS message are different in structure, syntax and in the way that data-elements are ordered, but they are equal in their content. Essentially you can always use an ANSI X12 or an EDIFACT message, for any business transaction the differences in content are minor. Since the contents of these two messages is equal, a translator would - when looking at an XML/EDI message - essentially not have to care how the data-elements are grouped inside the message. There should be some structure for the translator in the message, for instance header data should be separated from details information (line items). Since all the data-elements are prefixed by their tag, a translator would always be able to map each data-element from the XML/EDI message to its place in an in-house file. This opens up an opportunity for presenting the information on a Web site. Essentially what the creator of an XML/EDI message could do, is arrange the data-elements in such a way that they make sense for a user to look at on a screen, where of course the tags of the XML file would be translated into a meaningful description. The Global Repository From this point of view there could be a relatively easy fusion between EDIFACT and ANSI X12. Essentially every data-element one can find in ANSI or in EDIFACT could be placed inside the XML/EDI file. What would be required is to set up a repository in which the tags for the XML files are listed with the corresponding EDIFACT dataelement number, the corresponding ANSI X12 element number, and a description. This description can be prefixed by a language code. In the repository you can have multiple language codes; language not only in the sense of human language but even in the sense of American-English or English-English or even Retail-English and Manufacturing-English. Big battles are going on in EDIFACT standardization groups on the wording of the explanation of the data-elements. These issues can be solved if every organization that would like to have its own meaning for certain data-elements, could add translations of these data-elements under their own language code to the repository. In this way the battle between the Americans and the English, whether it is "stock" or "inventory", can actually be solved quite easily. By setting up one global repository on the Internet, CEFACT can assume responsibility for the creation of new tags based on a corresponding EDIFACT data-element number and the standard description, while other organizations can assume responsibility for a language code or the corresponding element number in different standards. The repository as such can also act as the translation for when an XML/EDI file is to be put on the screen for a user, being French or English or whatever nationality. It could be the identical file, but on the screen it will come up in the reader s own language. The repository here plays an essential role, because in it we will find each data-element that can possibly be used in an XML/EDI message. In the repository every XML-tag should be defined with the corresponding ANSI X12 code and the corresponding EDIFACT code and maybe an identical code for some other European standards that are national or proprietary. The description can be in different human languages, which would make it very user-friendly. To have a local copy of the repository available would mean the user will not have to wait until each of the XML tags has been translated into his preferred language. Another method would be to use caching methods to keep only the most recently used translations local. Even if XML/EDI is not the ultimate solution, a global repository would be extremely useful for conventional EDI and other forms of EC, because it would provide an independent Data Dictionary which could be used by applications.
page 6 XML Tags A big debate is going on in the XML/EDI group on what the structure of the tags should be. Some advocate the use of the full description in the tag and others the use of the ANSI element number as the tag and even others a unique number that would include the standard version of the directory, the segment it resides in and the data-element it represents. In the view of the EEMA/EDI Work Group there should be a sequential numbering of the tags for XML/EDI; this would be an identifying code only, starting with a letter. This would provide a neutral starting point for all old standards and would be most efficient in size. As far as the messages are concerned, as stated before, the header information should be separated from the detail information, or maybe there should be a looping mechanism at a group level. Other than that the translator, from a technical point of view, does not require any further structuring. This offers a lot of freedom, but the essence of what EDIFACT is will still be there. The EDIFACT UNSMs will always prescribe what data-elements would be legal in a message. In that way the know-how of business processes and transactions that is captured in these UNSMs does not go to waste; on the contrary it is now exploited in a much more open and versatile way. The role of the UN When the fusion between ANSI X12, EDIFACT and all other EDI standards takes place in a proper way it should be under the auspices of the UN so it is global, public domain, open and available for anyone. Today this is not the case with the ANSI standards and many other EDI standards that are only available at considerable cost. Of course today the EDIFACT standard is already in the public domain and can easily be obtained through the Internet. According to the EEMA/EDI Work Group it is important for the CEFACT to make a statement on whether it is going to support XML/EDI and help to facilitate the merger between UN/EDIFACT and ANSI X12. This could save the whole standardization effort a lot of time. It would allow legacy systems in the US to keep on using ANSI X12, either in its native form or in an XML/EDI format. The same would be true for the legacy systems in Europe, where EDIFACT can remain to be used and XML/EDI messages can be used as well. It would be a great step forward for the standardization effort, since the standardization work can basically be devoted itself to determining what elements may appear in a message and less to where exactly they should appear or how they should appear. This definitely holds a lot of promise for EDI in its use as the backbone of Electronic Commerce.