XML: No Magic Problem Solver
The Internet is a wonderful source of technical jargon and a bubbling cauldron
of alphabet soup. FTP, TCP, DSL, and a host of additional TLAs (three-letter acronyms)
litter the speech of engineers and programmers. Every now and then, however, one of
those bits of jargon breaks away, leaving the world of geek-speak to become that most
sought-after of technological developments: a Magic Problem Solver.
A Magic Problem Solver is technology that non-technologists believe can dissolve
stubborn problems on contact. Just sprinkle a little Java or ODBC or clustering onto
your product or service, and, voila, problems evaporate. The downside to Magic Problem
Solvers is that they never work as advertised. In fact, the unrealistic expectations
created by asserting that a technology is a Magic Problem Solver may damage its real
technological value: Java, for example, has succeeded far beyond any realistic
expectations, but it hasn’t succeeded beyond the unrealistic expectations it spurred
Today’s silver bullet
The Magic Problem Solver du jour is XML, or Extensible Markup Language, a system for
describing arbitrary data. Among people who know nothing about software engineering,
XML is the most popular technology since Java. This is a shame since, although it really
is wonderful, it won’t solve half the problems people think it will. Worse, if it
continues to be presented as a Magic Problem Solver, it may not be able to live up to
its actual (and considerably more modest) promise.
XML is being presented as the ideal solution for the problem of the age: interoperability.
By asserting that their product or service uses XML, vendors everywhere are inviting
clients to ignore the problems that arise from incompatible standards, devices, and
formats, as if XML alone could act as a universal translator and future-proofer in the
post-Babel world we inhabit.
The truth is much more mundane: XML is not a format, it is a way of making formats,
a set of rules for making sets of rules. With XML, you can create ways to describe
Web-accessible resources using RDF (Resource Description Framework), syndicated content
using ICE (Information Content Exchange), or even customer leads for the auto industry
using ADF (Auto-lead Data Format). (Readers may be led to believe that XML is also a
TLA that generates additional TLAs.)
Notice, however, that using XML as a format-describing language does not guarantee that
the result will be well designed (XML is no more resistant to "Garbage In, Garbage Out"
than any other technology), that it will be adopted industry-wide (ICE and RDF are
overlapping attempts to describe types of Internet-accessible data), or even that the
format is a good idea (Auto-lead Data Format?). If two industry groups settle on XML to
design their respective formats, they’re no more automatically interoperable than are
two languages that use the same alphabet–no more "interoperable," for example, than are
English and French.
Three sad truths
When it meets the real world, this vision of XML as a pain-free method of describing
and working with data runs into some sad truths:
Sad XML Truth No. 1: Designing a good format using XML still requires human intelligence.
The people selling XML as a tool that makes life easy are deluding their customers–good
XML takes more work because it requires a rigorous description of the problem to be
solved, and its much vaunted extensibility only works if the basic framework is sound.
Sad XML Truth No. 2: XML does not mean less pain. It does not remove the pain of having
to describe your data; it simply front-loads the pain where it’s easier to see and deal
with. The payoff only comes if XML is rolled out carefully enough at the start to lessen
day-to-day difficulties once the system is up and running. Businesses that use XML
thoughtlessly will face all of the upfront trouble of implementing XML, plus all of the
day-to-day annoyances that result from improperly described data.
Sad XML Truth No. 3: Interoperability isn’t an engineering issue,
it’s a business issue. Creating the Web -- HTTP plus HTML -- was
probably the last instance where standards of global importance were
designed and implemented without commercial interference. Standards
have become too important as competitive tools to leave them where
they belong, in the hands of engineers. Incompatibility doesn't exist
because companies can't figure out how to cooperate with one
another. It exists because they don’t want to cooperate with one another.
XML will not solve the interoperability problem because the
difficulties faced by those hoping to design a single standard and the
difficulties caused by the existence of competing standards have not
gone away. The best XML can do is to ensure that data formats can be
described with rigor by thoughtful and talented people capable of
successfully completing the job, and that the standard the market
selects can easily be spread, understood, and adopted. XML doesn’t
replace standards competition, in other words, but if it is widely
used it might at least allow for better refereeing and more decisive
victories. On the other hand, if XML is oversold as a Magic Problem
Solver, it might fall victim to unrealistically high expectations, and
even the modest improvement it promises will fail to materialize.