Excellent news! This is the last issue of ITworld's XML in Practice
newsletter! Why is it such good news? Well, when was the last time you
read a newsletter on HTTP, on ASCII, or on TCP/IP?
While you ponder the implications of this analogy, let me take the
opportunity to invite you to join me over on ITworld's E-Business in the
Enterprise newsletter [1] where I will continue writing about XML, EAI,
Web Services, and related technologies from next week onward.
Back to the issue at hand. David Megginson, father of the SAX API,
SGML/XML guru of long standing, once said that XML's ultimate success
will be that it will disappear to become an integral part of the
plumbing of our IT infrastructure [2].
That day is upon us friends. Although many questions remain concerning
XML processing, modeling, security and so on, XML itself is now firmly
established as an immovable meme in the technology landscape. Although
the XML meme is immovable, the technological substrate is not. I predict
we will continue to see movement in that substrate -- mostly in the form
of a contraction -- over the next few years.
Lets look at some aspects of XML that justify its inclusion in the
exclusive club of "no-brainer" plumbing components such as TCP/IP. We
will then turn to a possible further contraction of "standard" XML in
the future.
1. XML is more complex than it looks (but only the engineers worry about
that)
Numerous complexities have not and will not go away from XML if you
interpret the specification literally and implement it in its totality.
However, these complexities have been relegated to "implementation
detail" -- just like HTTP header semantics, ASCII line end encoding, and
TCP/IP routing. So we have, at business/technology management level,
"just use XML" as equal billing with "just use HTTP" and so on. Although
some of the "implementation details" are significant, given sufficient
engineering talent, they can be overcome.
2. XML as practiced differs significantly from XML as envisaged.
The original battle plan for hatching XML from SGML was to allow XML
documents to be processed without re-checking the structure against the
schema. This differentiation between validated and well-formed XML was
one of the big distinguishing features of XML over SGML. However, in the
back of the minds of us SGML types, we envisaged that the schema would
always actually *exist* to be used by back-end processes for care and
feeding of the data.
To the surprise of many -- myself included -- developing XML
applications without the safety net of a schema, appears to be very
commonplace. Over the last year, I have been involved in a number of
projects where my first task was to reverse-engineer a schema form an
existing set of XML instances.
Another example of XML as practiced differing from XML as envisaged is
the almost complete abandonment of XML's built-in physical data model --
in other words the entity structure. W3C XML Schema has probably put the
nail in that particular coffin by eschewing entity support completely.
Further evidence to support this is that only a small fraction of the
XML community (primarily publishing people with SGML backgrounds) even
noticed!
Aspects of XML such as these remind me of the RS-232 standard from many
years ago. As initially specified, serial cables had twenty-five pins. I
remember building RS-232 cables by hand with a soldering iron and two
25-way RS-232 connectors. It was not unusual to only need *three* of
these twenty-five pins to get the job done. Over the years, the number
of pins in serial connectors dropped to nine where it stabilized and
served the industry well for many years.
The differences between XML as practiced and XML as specified would seem
to point to the possibility of an XML contraction in the future -- like
moving from 25 pin to 9 pin RS-232. What will be the cause of this
contraction?
My guess is Web Services. This emerging meme uses only a fraction of XML
as specified. So much so, that many proponents of Web Services go about
their work wielding XML everywhere without appreciating that they are
just using a subset of XML as specified. Many younger developers wield
the RS-232 nine-pin interface without every realizing that it is a
subset of a twenty-five pin interface from days of yore.
So where to from here? If we follow the RS-232 analogy, then the next
big thing is inter-operability. RS-232 standardized inter-connectivity
for a generation of communication-centric application developers. Once
the inter-connectivity was sorted, all the effort when on building
inter-operability on top of it. In a word "protocols".
Likewise, XML has provided basic inter-connectivity to a generation of
information-centric application developers. Now that the base level of
information inter-connectivity has been established, all effort will
move to building inter-operability on top of it. In a word "semantics".
Inter-operability is hard because shared meaning is a really hard
problem that is only partially technological in nature. Certainly, XML
does not solve it. Most successful shared meaning is established by one
carbon based life form exchanging common signs with another carbon based
life form. Nobody knows how to do that with computers yet.
But we are working on it, and XML provides another vital part of the
plumbing to get there. But it is only a part of the plumbing. Now that
it has solidified (more or less), we can safely turn our attention
elsewhere.
NOTES
[1]
http://reg.itworld.com/servlet/Frs.frs?Script=reg_script_2&Context=START#
[2] http://www.martinig.ch/mt/facts/jan01.html
