Is XML the answer? Depends on the question.
- By Michael Goulde
A common joke around my office is that any problem in the world can be fixed
using some combination of duct tape and the eXtensible Markup Language (XML).
Case in point: A recent television program ran a profile of an inventor who
created a bear-proof suit of armor held together with duct tape. Although XML
wasn't used in this particular example, developers are using the technology
as a component in solutions to some of the more vexing and persistent challenges
facing IT today.
Many of the most difficult tasks lie in organizing and delivering
information across the Web, as well as in exchanging information among incompatible
systems and applications.
XML provides a syntax that can be used to construct messages that can be understood
by any application. This makes data movement much simpler, and requires far
less effort than having to code unique interfaces between each application.
This is possible because XML is text-based, self-describing and gaining acceptance
as a global standard.
One of the reasons XML has captured so much interest so quickly (Version 1.0
of the XML specification was released in February 1998) is that it represents
a parsimonious solution to a wide variety of problems. There are three sets
of users who have a very high level of interest in XML. The first group includes
Webmasters and other designers of Web-based information systems who use HTML
to mark up information for presentation, but have no way to structure the information
they send to browsers. By providing structure to the unstructured Web data in
a standard way, a Web query can deliver a much more useful set of results, increasing
the value of the information.
The second group of users have toiled for years with the Standard Generalized
Markup Language (SGML) to create structured documents such as training manuals
and technical documentation. Although HTML is derived from SGML, SGML in general
is not well suited to the Web environment because it is extremely complex --
something that has also affected its universal adoption. XML is an SGML derivative
that is not only easier to use on the Web, it has garnered wider adoption. These
users have also become very active in World Wide Web Consortium (W3C) working
groups that are hammering out additional specifications and standards to ensure
that XML meets many of the same application requirements as SGML.
The third set of users fascinated by XML are a set who were not originally
targeted by the W3C's XML efforts. But very early on, application developers
building distributed applications -- and faced with difficult challenges around
application integration and interoperability -- saw XML as a way to free their
applications from the tyranny of over-the-wire binary formats that made it impossible
to link applications together in real time. These developers, many from the
Java community, but equally as many using Microsoft tools, quickly realized
that they could use XML syntax in their messages and, because of the self-describing
nature of XML documents, applications could exchange data without having to
be explicitly written or compiled to do so. Freedom! This group has now expanded
to include developers who want to extend EDI, link networks of suppliers and
customers, create dynamic marketplaces, and perform other heretofore impossible
tasks over the Web.
Open standard/closed vocabularies
The XML specification provides an open, standard syntax that can also be used
to create vocabularies -- a collection of tags used to structure documents.
XML itself does not specify the semantics of these vocabularies. Because of
this, incompatibilities can arise, as well as proprietary vocabularies that
can result in incompatible solutions to the same problems. For example, XML
tells us how to use angle brackets to create elements and structure attributes
of elements. But it doesn't tell us what the specific elements in a document
should be. There are two issues here. The first is when the same tag has different
meanings. I may create a vocabulary that uses as a tag for how
fast one should travel, while someone else might use to refer
to an attribute of photographic film. (I've omitted the end tags that XML requires,
such as , for clarity, but don't you omit them!) The other issue
is when two different vocabularies use different words for the same thing. For
example, one might assign a tag to each product while another
might assign a tag.
Fortunately, XML's features make these incompatibilities less of a problem
than when these attributes are expressed in compiled form. Because XML documents
are human-readable and use standard character sets instead of binary encodings,
it is simpler to create mapping layers to convert a document using one markup
language (vocabulary) into a document marked up with a different, but related,
set of tags. So, if my markup language uses the tags and
, and your markup language uses and ,
it is a fairly simple matter to map one to the other. In fact, the eXtensible
Stylesheet Language (XSL), a W3C specification related to XML, provides a mechanism
for doing this mapping. Developers are even creating XSL-based transformation
engines to actually carry out the conversions on the fly. All you need is a
template that shows the mappings. The beauty of this is that you can map an
unlimited number of other vocabularies into your own simply by creating a new
XSL style sheet.
But is this really a good thing? Wouldn't it be better if everyone agreed
on the same vocabulary? Universal uniformity would be ideal, but history teaches
us that universal agreement on things like this is just a utopian dream. XML
isn't Esperanto. It is not a common language meant to replace all others and
be spoken by all. It is more like ASCII, whose character sets can be used to
create text in many different languages. I can recognize all the characters,
but I cannot speak all the languages. (Note that XML doesn't actually use ASCII,
but Unicode, of which the common ASCII character set is a subset.)
So, what approach should you take?
In spite of the efforts of CommerceNet, Commerce One, Ariba, Microsoft and
others, XML will never be used to create a universal business language. Accept
the fact that everyone will take the approach that makes the most sense for
them and use the tools that XML provides to cancel out the differences.
This isn't to say that efforts at standardization are fruitless. There is
a common good to having agreement on a core set of tags whenever possible. Industry
groups in dozens of vertical sectors are working to come to agreement on industry
vocabularies. To the extent they are successful, exchanging data and information
will become far simpler than it has ever been. Efforts underway to map EDI messages
to XML take advantage of pre-existing work in this direction. In the long run,
we will likely see agreement on a common set of tags in applications where data
must be frequently exchanged across enterprise boundaries, and less agreement
where data is less frequently exchanged. But at least we will have a mechanism
for easily handling those differences so that we can invest our time and resources
in solving more difficult challenges -- like how to get duct tape off a wall.
Customers often ask whether they should just wait until all the efforts at
defining vocabularies have settled down before adopting XML. My recommendation
is generally not to wait, but to go ahead and do the work necessary to define
your company's data schema. This effort is not unlike past data modeling efforts
that were often shelved before they were completed -- but now there is one key
difference. Defining an XML schema for business objects that are relevant to
your business processes has a direct application. There are XML servers that
can load those schemas and serve data that is structured using those schemas.
There are also tools for building applications and exchanging data. Previously,
the developed data model sat in binders on the shelf. Today, my XML schema is
something I can use immediately.
As things evolve, industry vocabularies develop or as my business partners
introduce vocabularies that differ from my own, I won't have a problem. Using
XSL, I can easily map the work I have done to the work others have done. In
fact, I can often simply replace my vocabulary with another. XML's simplicity
approaches elegance in the sense that it is a simple solution to a complex problem.
The beauty of XML is that it is almost completely invisible. Tools will hide
the XML syntax from the application developer, the database programmer, the
Web designer and the end user. Unlike HTML, being able to write XML syntax by
hand will not be the sign of a "real" Webmaster. Understanding how to apply
XML and how to structure data hierarchically to best take advantage of XML will
now be the sign of a clever application developer.