XML for Electronic Document Interchange

[Previous] [Next]

XML is a standard created by the World Wide Web Consortium (W3C). The W3C is a consortium of companies devoted to creating and maintaining core Internet technologies. XML is a powerful syntax that allows companies to create structures for the efficient interchange of information. We'll see what XML looks like in Chapter 4.

The problems with EDI over the last quarter century (long development times, varying requirements across companies, and difficulty implementing a one-size-fitsall specification) should be a lesson to those working on interchange standards that use XML. A group called XML/EDI is working on a more open version of the EDI specifications, hoping traditional EDI users will move over to XML as their data interchange syntax. That group is not alone. Many groups are now working towards the same end—that is, to create a universal way of doing business with others by using XML as the data-definition syntax.

Another of these efforts is the ebXML Initiative. The "eb" stands for "electronic business." The United Nations /CEFACT and the Organization for the Advancement of Structured Information Standards (OASIS)—an XML industry group—are working on ebXML. The goal of ebXML is to use a standard set of XML objects to facilitate international trade. The goal of the ebXML Initiative is to develop a technical framework that will enable the use of XML in a consistent manner for the exchange of all electronic business data. The group's list of participants reads like a who's who of international trade: Ariba, Amazon.com, Bank of America, Boeing, CommerceNet, Dunn and Bradstreet, IBM, Microsoft, Oracle, Sun, and many other companies around the world. There are many specs being developed by other groups in this space. There are cXML from Ariba, CBL from CommerceOne, the RosettaNet Framework from RosettaNet, and eCo Framework from Commerce Net, to name a few.

Other industry-specific efforts include the Financial Information Exchange (FIX) spec for trading securities information, HL7 for exchanging medical records, ACORD for property and casualty insurance information, J2008 for the automotive industry, and many, many more. All these efforts use XML as their base syntax.

These specifications will probably result in a set of specifications called schemas (mentioned at the beginning of the chapter) that will describe certain business documents such as invoices, purchase orders, medical records, and securities transactions. The schema is a critical piece of the e-commerce solution. I'll discuss schemas in detail in Chapter 4.

XML and E-Commerce

So where does XML fit into all of this? Everywhere. XML is just a set of rules—a syntax—for marking up data. It is a small, standard, compact syntax, however, and that's where its value comes in. To engage in any business transaction, you must communicate clearly with your business partners. XML provides a syntax for communicating in a direct, precise way by identifying each piece of information required to complete a transaction—whether that transaction is shipping credit card information in secure packets around the Internet or serving up a free HTML page from a Web server to a 14-year-old looking for the latest MP3 tracks.

Another aspect of XML and e-commerce is trust. If you don't trust someone, you are not going to do business with him, either face to face at the town bazaar or anonymously across invisible national borders over the Web. XML can provide a level of verification because information about your transaction can be carried right along with it.

Lingua Franca

When a Japan Airlines (JAL) pilot flies a jumbo jet into Charles de Gaulle airport in Paris, he needs to communicate with the tower controller in a common language. The pilot's native language is Japanese. The tower controller's native language is French. If they choose Japanese, it would be the tower controller's responsibility to understand Japanese. Likewise, the controller would also need to know German, Italian, English, and every other language of pilots landing at her airport.

If the pilot and controller communicated in French, it would be the pilot's job to do the translation. The pilot would also need to know German, Italian, English, and any other language spoken by native tower controllers where the pilot landed.

Either one of these scenarios would be expensive, time-consuming, and potentially dangerous. For the sake of safety and the efficiency of a transaction, the world's air traffic control system decided on a standard language to communicate between planes and ground control systems. That language is English.

When the JAL pilot wants to communicate with the tower, he must translate in his head from his native Japanese to the foreign English. He will compose a sentence in English and transmit it to the tower by speaking into a microphone. The radio sends the English sentence to the tower, where the tower controller hears it.

The tower controller translates the English sentence into French, her native language, so that she can process it in a way that is easiest for her. (Of course, professionals such as these probably speak and think in English, so they can process the information faster, but I hope I'm making my point!)

NOTE
It is interesting to note that when that same pilot returns to Japan, he communicates with the tower in English because there are other planes in the area with non-Japanese-speaking pilots who might need to overhear the conversation.

In the same way, an XML document is usually created on the fly by some application. This document contains all the information necessary to effect the transaction. This recently generated document is sent to our business partner expressed in XML, a syntax foreign to the original generating application. Our partner's receiving application gets the XML stream. That stream is also foreign to this application, so it is translated by the application into a native language for processing. After it is processed on the receiving end, it is no longer an XML document. The data contained in the document has been loaded into the system, using the boundaries indicated by the XML tags to describe the data.

There's a phrase for this: lingua franca. My American Heritage Dictionary defines this as follows:

1. A medium of communication between peoples of different languages, and
2. A mixture of Italian with Provençal, French, Spanish, Arabic, Greek, and Turkish, formerly spoken on the eastern Mediterranean coast.

Let's forget about the second definition for now, and replace "peoples of different languages" with "computers of different configurations."

XML is thus the lingua franca of e-commerce transactions. This isn't quite accurate, because XML itself is not the vocabulary—that is the job of the schema—but XML is the syntax used to exchange the data and make the transaction happen. (I'll include more on this when we talk about developing schemas for industry groups in Chapter 3.)

XML and Processing Languages

XML is an open standard owned not by a single company but by a consortium of highly competitive companies in many industries that have realized the great benefit to all of agreeing on a simple syntax for exchanging information.

Because of its open status, XML works on any platform with any programming language. XML really doesn't do anything—it's just a syntax that provides a way of thinking about and representing your data. The key benefit of XML is that it allows you to separate your data from the processes that act on your data.

You have probably heard a lot about XML and Java—XML for representing data and Java for processing it. The pairing of XML and Java makes a lot of sense because of the open, platform-independent nature of both. Developers can create cross-platform applications in Java and use XML to exchange data between them.

But Java isn't the only language that works well with XML. You can use Microsoft Visual Basic, Microsoft Visual C++, Perl, and even COBOL to create and read XML data. The list of languages that work with XML is as long as the list of languages. Because XML merely specifies rules for representing data, any programming language can benefit from XML's neutral data-description ability.

Unlike HTML, which has a fixed set of tags, XML gives you the flexibility of creating your own tags. You can call things whatever you want. For example, you might have tags named Title, Heading, Invoice Number, and so on. XML tags will usually represent real data.

If you move data around in text files, you have to create your own syntax and your own rules for taking a text file and getting the data out of it. If you use XML, you don't have to do that. You merely need to create an XML document that is syntactically and semantically correct and then use a parser to read the XML and extract the data from it. There are numerous XML parsers available, including the one that ships in Microsoft Internet Explorer, and they are typically free.



XML and SOAP Programming for BizTalk Servers
XML and SOAP Programming for BizTalk(TM) Servers (DV-MPS Programming)
ISBN: 0735611262
EAN: 2147483647
Year: 2000
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net