The real benefit of XML

A chief executive officer once asked me, "Does our new World Wide Web site use XML?" The site didn't use it at the time — for some good reasons — but the CEO was eager to use it. XML (short for Extensible Markup Language) and B2B (business to business) are two of the hottest buzzwords around. You could probably incorporate "XML4B2B.com," put up a Web site and make a killing in the stock market.

But XML's value goes beyond Web sites. Many agencies have a mix of systems: some legacy mainframe, some client/server, some on the Web. XML can enable all of them to communicate.

The traditional approach to interfacing two systems involves one system reading the database of another or one system making a "call" through an Application Program Interface or a similar mechanism, possibly using a Remote Procedure Call to reach across a network. System A makes a call to System B and receives data in return.

There are several problems with this approach. First, every connection between two systems will most likely require custom programming. If many systems are involved, a lot of programming will be needed. Worse, if there are logic or data changes in one system, the interface will probably need to change — again, more need for programming. Finally, these interfaces are fragile: If some data gets "dropped," or parameters don't exactly match, unpredictable results can occur. Error handling and recovery are quite difficult under this approach.

XML solves or mitigates many of these programming problems. Instead of making calls and passing parameters, systems communicate by reading and writing files that contain both data and structural information. The data elements in the file are "tagged," meaning that they are enclosed in a block of data that is preceded by a data element name. A program can tell by looking at the file what the data elements are — unlike traditional approaches, in which the program assumes the meaning of the data from its position in a record or its association with an argument in a function call.

XML also has a Document Type Definition. A DTD can be written to define the structure of a particular kind of XML document or file. For example, a DTD for an invoice might specify that an invoice has a number, a billing address and so on. The commercial programs available to help write a DTD and validate XML files can eliminate custom programming.

The final piece of the puzzle is the style sheet, which controls presentation of the XML. If you have, for example, a report in XML form, you can have one style sheet for presentation on the Web and another for print.

There are even XML parsers that allow you to use XML to communicate with relational database management systems like those from Oracle Corp.

XML does require planning and time, which are always in short supply. But in the long term, we'll be seeing more and more XML. It's worth a serious look.

— Bragg is an independent consultant and systems architect with extensive experience in the federal market. He welcomes your questions and topic suggestions at tbragg@acm.org.