![[INET'99]](/web/20100311063223im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/inet99sm.gif)
![[ Up ]](/web/20100311063223im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/up.gif)
![[Prev]](/web/20100311063223im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/prev.gif)
![[Next]](/web/20100311063223im_/http://www.isoc.org/isoc/conferences/inet/99/proceedings/next.gif)
Graham R. SMITH <graham.r.smith@si.shell.com>
Shell Services International BV
Netherlands
Extensible mark-up language (XML) and the Internet will dramatically reshape the electronic data interchange (EDI) landscape. By driving down the costs and complexity, EDI will become a truly ubiquitous technology that will reshape business as we know it.
Over the past several decades, corporations have invested billions of dollars in automating their internal processes. While this investment has yielded significant improvements in efficiency, that efficiency has not been extended to external processes. In effect, companies have created islands of automation that are isolated from their vendors and customers; including their trading partners. The interaction among companies and their trading partners remains slow and inefficient because it is still based on manual processes.
Manufacturers and suppliers struggle with these issues all the time. Suppliers are caught up in the challenge, as they must feed parts to multiple manufacturers. They must be sure that manufacturers have parts when they are needed, but they have to be careful not to overstock their products when manufacturer demand is not high enough to sell them.
The supplier may itself be a manufacturer and have its own suppliers. A series of businesses that feeds parts to one another in sequence is known as a supply chain. Suppose manufacturer X decides to maximize the efficiency of its link in the supply chain. It wants to integrate its manufacturing resource planning (MRP) systems with the planning systems of its suppliers, thereby providing each side with rich inventory information in real-time. The manufacturer benefits by having access to up-to-date availability of information of supplier parts, including parts delivery schedules. The supplier benefits by having access to the manufacturer's current parts inventory levels and to the manufacturer's expected rate of depleting the inventory.
Manufacturer X does not want to lose an arm or a leg or a bevy of shareholders in the process of implementing the solution. It requires an inexpensive solution that it could put together in a period of weeks, rather than in a period of months or years. This rules out traditional electronic data interchange (EDI).
Traditional EDI is based on fixed transaction sets. These transaction sets are defined by standard bodies such as the UN Standard Messages Directory for Electronic Data Interchange for Administration, Commerce and Transport (EDIFACT), and the American National Standards Institute (ANSI) Accredited Standards Committee X12 sub-group.
EDI is the process for exchanging data in electronic formats between heterogeneous applications and/or platforms in a manner that can be processed without manual intervention. However, at the time the technology landscape was very different from what it is today; lacking ubiquitous powerful CPUs, a common transport, and a file format that allows for flexibility, they defined strict transaction sets. These transaction sets addressed the needs for handling the data. In other words, the business rules were embedded into the transaction set.
The incorporation of business rules into the definition of the transaction set causes many problems because
In short, the use of fixed and rigid transaction sets, while necessary at the time, have limited the value of EDI, and therefore stunted its growth.
There are tremendous benefits from the adoption of EDI within the supply chain, and there are structural problems associated with traditional EDI. The obvious question is: "How can the problem be fixed?"
Fortunately, there are new technologies emerging that have the potential to completely reshape the EDI landscape. As it stands today, EDI is currently implemented in a one-to-one manner between exchange partners (trading partners). These partnerships can be extended through the tiers to create a supply chain. This is all starting to change, as the new paradigm is the SUPPLY WEB.
The supply web is based on the use of XML (extensible mark-up language), the Internet, Internet services, and database connectivity to create a network, or web, of trading partners.
Implementation and operational costs are set to plummet, exchange partners will implement one size fits all solutions, adoption will skyrocket and the benefits are not set to be limited only to the exchange partners, but they will be driven down to end users as well. EDI will become as commonplace as e-mail.
What is XML and how will it affect EDI? XML is a computer language for describing information. So to is HTML. XML improves on the HTML approach and makes the Web a better place to do business, to learn, and to have fun. HTML is a great technology and has changed the world. However, a great deal of useful information is lost when data are converted into HTML -- information that, if preserved, can be used to build a whole new world of business-to-business computer applications on the Web.
Compare these two documents:
Document 1 (HTML snippet): <h1>invoice</h1> <p>From: A.N.Other Company <p>To: The Next Company <p>Date: 19 January 1999 <p>Amount: $250.00 <p>Tax: 17.5% <p>Total Amount Due: $293.75 Document 2 (XML snippet): <invoice> <from>A.N.Other Company</from> <to>The Next Company</to> <date year = '1999' month = '1' day = '19'/> <amount currency = 'dollars'>250.75</amount> <tax rate>17.5</taxrate> <total amount due currency = 'dollars'>293.75</total amount due> </invoice>
Put yourself in the computer's position (if it could think for itself). Which document would it choose and find easier to process? Which of the two captures the most useful information? Which one has future potential uses?
The distinction illustrated in these two document snippets is the very essence of XML. XML is all about preserving useful information -- information that the computer systems can use to be more intelligent about what they do with the data in our business processes.
If you know how to work with HTML you might think to yourself, why not just add tags for <invoice>, <taxrate>, etc. This step could be taken, but where does that process end? No set of tags, no matter how large; will ever come close to providing all the tags we might conceivably need. There has got to be a better way.
Enabling technology to the rescue! There is a better way and it exists and it's called XML. Don't be fooled XML is not a go faster HTML. It is fundamentally a different technology that is set to and will liberate information from the shackles of a fixed-tag set. If, for example, you are describing the invoice, why not call it an <invoice> rather than level1 heading.
There is a saying "call a spade a spade," it means speak plainly. This saying captures the core idea of XML exactly -- "call a spade a <spade>"!
In the way the hype around the Internet has grown over the past few years it would lead one to believe that the concept of electronic commerce did not exist before the Internet became a household word. In fact, electronic commerce has been bubbling around for at least the past 25 years. Specifically, various efforts have lead to the creation of a variety of EDI standards.
The best known standards are EDIFACT and ANSI X12. With the amount of business forecasted to be conducted via the Web and related technologies, is it any wonder then why people ask where the traditional EDI fits into the Internet scheme of things.
The EDIFACT standard is a message format for business-oriented transactions, such as purchase orders, invoices, call-off orders, etc. The EDIFACT format is very definitely not directly related to HTML or XML, as the following illustrates:
UNB+UNOA:2+ESTEC(JBUTU)+ESA(CMO)+980316:0000+1 UNH+1+PCINFR:1:2:ES' RFF+AEP:COLUMBUS PHASE 1:048' DTM+317:980301:101' UNS+D' RFF+WBS:048'MOA+209:110700:AU'DTM+295:980301:101' RFF+WBS:048'MOA+211:55400:AU'DTM+295::101' RFF+WBS:048'MOA+209:241800:AU'DTM+295:980401:101' RFF+WBS:048'MOA+211:83800:AU'DTM+295::101'
An EDIFACT message consists of compressed data segments that are interpreted via a separate field definition table. Fields are themselves interpreted with reference to a data dictionary. The mechanism by which the order of the data segments is prescribed for transmission is reminiscent of the functionality provided by XML document type descriptions (DTDs). Segments can be mandatory, optional, or conditional. They can be repeated a predefined number of times. For each data segment, the field definition table and element dictionary allow control over the number of characters in each segment and their types (numeric, alphabetic, and so on).
Parties wishing to exchange EDIFACT messages would contract between themselves to establish a private, often proprietary, communications network (known as VAN -- value-added network). They would then develop conversion programs to convert between their own data formats and the EDIFACT format agreed for transmission. As a consequence of this design, each new party to join in the EDIFACT conversation had to develop new software.
The closed/per-user-customized nature of EDI has contributed to the significant cost of using EDI and has restricted its uptake to all but large enterprises.
The original intent of EDIFACT was to provide a digital version of a paper form. The idea was to reduce the inherent waste in the paper loops so common in business.
EDIFACT messages can be converted to XML and vice-versa. Moreover, once represented in XML, the Internet can be used as the transport medium in place of the VAN. These simple to state facts hold out the possibility of spreading the potential user base of traditional EDI beyond the proprietary networks from which it came into the global Internet. Perhaps most important, the meta-language nature of XML allows XML DTDs to be used to customize messages rather than hand-craft version programs as in the case of EDI.
The world of business has changed dramatically since EDIFACT was designed. Perhaps the biggest change has been the Internet itself. Electronic business transactions no longer consist primarily of batch transfer of paper-orientated data fields from one computer to another. Modern business transactions are more immediate and more interactive.
The initiative to bring EDI and XML together while retaining the best features from an electronic commerce perspective can be summarized below.
The Web will bring other possibilities into play such as the use of Web automation, search engines, and Web agents to perform electronic commerce tasks.
XML has many advantages as an EDI format. Around the globe a lot of time and effort is being spent on XML and XML expertise. The primary goal of EDI -- reduction in the cost of commerce -- is being well served by the XML phenomenon. Apart from market success, the XML open systems format, human readability, and the concept of a DTD all have much to offer EDI.
XML/EDI developers envision the emergence of specialized data manipulation applets that are XML/EDI aware. XML/EDI transactions routed through Web-based data-bots could be used to automate processes such as forms processing, business document routing, regulation compliance, and so forth.
XML/EDItors are envisioned as interactive tools for the creation of business forms. The idea is to download XML/XSL descriptions of the business document into the Web browser, where the user is then guided through the process of form filling in order to meet the requirements of the business transaction.
The creation of electronic catalogue formats based on EDI/XML standards are set to open up a new world for buyers and sellers alike. In the future, it will not be necessary for the visitor to the virtual store to be human. Purchasing Web agents will be able to roam XML/EDI sites, gathering pricing information. They may have to report information back to their human user. They may also have embedded discretionary e-cash buying power based on business rules established by their creators. The business (EDI) community stands to benefit from this in many ways. The Internet is clearly where the majority of electronic commerce is headed. XML is where the Internet is headed. Therefore a marriage between EDI and XML would seem to be preordained.