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 [email protected].