 |
|
|
Abstract
The applications of XML are not limited to the those that run on the Web. The relationship between XML and the Web, though, is special. Not only is XML key to the Web architecture, but issues of Web architecture are key to how XML moves forward.
Table of Contents
The Web has become so much a part of our daily lives and our professional infrastucture that it's easy to forget how wonderful and unprecedented it is; the largest and most successful distributed information information application ever built. We ought to learn from our successes, not just from our failures.
XML is a creature of the Web, if only by ancestry, given its birth under the auspices of the Web Consortium. This essay will argue that the synergies between XML and the Web are more than an accident of birth; first, that XML makes the Web a better place; and second, that XML succeeds when informed by the Web, and fails when it tries to disavow its heritage.
For the first time since its birth a decade ago, the Web has a body (see http://www.w3.org/2001/tag) charged with writing down its architecture, and an (in-progress) document [Architectural Principles of the World Wide Web] (see http://www.w3.org/TR/webarch, Webarch from here on), which attempts to serve as a reference for that architecture.
Webarch was far from finished at the time this essay was written, and will remain under construction for some time. However, the key principles are well-established and worth learning from.
Web Architecture has three bases, presented here in order of decreaging importance:
A universal flat naming scheme based on the Uniform Resource Identifier (URI). The objects so named are referred to as resources.
A small, nonexclusive set of protocols (the most important being HTTP) whose formal structure is based on classic client-server principles; clients use servers to access representations of resources.
A moderately-sized, extensible, non-exclusive set of data formats to be used in interchanging resource representations.
The Web is unique among distributed information systems in that its naming scheme is entirely flat. Anything that has a URI is a resource and thus part of the Web; anything that does not have a URI is not.
It is a good thing to have a URI, and be part of the Web. Any unit of information or service is more useful on the Web than off it. This principle may seem painfully obvious and hardly worth making, but is a central pillar of the success of the Web; despite which, it is not always followed, usually at great cost, as we shall see.
It is possible to invest endless fruitless hours in debate as to what a Web Resource really is; such discussions quickly ascend to a metaphysical level which, while stimulating, tend to be of little practical value at the engineering level.
Web Architecture neatly dodges this conumdrum; a resource is that which is identified by a URI, and the Web provides no way to transfer it or to say what it actually is. The Web's key protocols, however, allow interchange (and update) of representations of resources. The representations may vary depending on when they are accessed, where they are accessed from, who is doing the accessing, and many other factors.
The basic operation in the protocol is simply to request the delivery of a representation of a resource. In practical terms, a representation is delivered as a small amount of metadata (HTTP or "MIME" headers) followed by arbitrary binary data, which may be anything from a few lines of plaintext to streaming full-motion video.
The other key characteristic of Web protocols is statelesness; each transaction is to be self-contained and self-describing. This, as much as any other factor, accounts for the Web's remarkable ability to scale up to insanely large-scale and high-volume operations.
Initially, the Web was more or less defined as the infrastructure for requesting and delivering HTML. However, with the advent of graphics early in Web history, HTML quickly a small minority of all the bytes exchanged over the Web. While HTML and its X-prefixed descendents seem unlikely ever to vanish from the Web scene, the proportion of Web traffic that is HTML can be expected to decline for the foreseeable future.
The last decade has seen a steady, monotonic increase in the number of electronic languages that are used on the Web, and there is no reason to think that this trend will stop any time soon.
The Web's dependency on XML is increasing every day. The reasons for this are not subtle or complex and can be covered quickly.
First, the Web's basic client-server architecture works best and most robustly when there is strong decoupling between client and server. A system designed to operate on a world-wide scale needs to be robust in the face of changes in software or hardware on either the client or server side. XML provides a strongly-decoupling interface; it is extremely difficult for client or server to "see through" an interchange of XML messages to find out what kind of agent is talking to, and develop dangerous dependencies on the details of that's agent implementation.
Second, the early Web did not do a good job of designing-in internationalization. XML does not by itself fix the well-known problems of internationalization at the URI and HTTP levels, but XML's careful attention to i18n issues forces implentors to take these issues seriously, and sets an example and standard for new Web components.
Third, the Web has a powerful hunger for new data formats. Multimedia, e-Business, and the Semantic Web, and Web Services are all eager generators and consumers of new electronic dialects. XML's extensibility makes it the obvious default choice for today's language designer. XML is not the the universal solution to all these problems - it is horribly verbose and is weak in the areas of design tools and schemas - but it certainly meets an urgent need.
The single most important lesson taught by the Web architecture is that of aggressive, brutal, minimalism.
The fundamental object - the resource - is unkowable by nature, can only be accessed through representations, and those representations may not even be available - the protocols cheerfully document, and their success relies on, the existence of "404 Not Found".
There is no notion of session, or transaction, or even state.
There is no distinction between naming and locating objects.
Information must always be requested from the server by the client - there is no proactivity or "push" semantic.
We can all agree that the Web would at some level be better if had more built-in components: semantic metadata about resources, or transaction machinery, or session management, or the ability to broadcast. But the trade-off for giving these things up has been overwhelmingly positive. Other information-system architectures with much richer semantics, designed for deployment on a world-wide scale, have failed to take hold; clearly the Web got at least some of the trade-offs right.
Three years into the twenty-first century, the "Web Services" hype has (mercifully) somewhat abated. However, the short history of Web Services does teach some valuable lessons.
First of all, the core idea of Web Services - applications built around the interchange of higly self-descriptive XML messages between agents with well-defined roles - is quite sensible, and in fact very consistent with ideas of Web Architecture.
However, the SOAP protocol, which is at the base of the Web Services stack, was, up through early drafts of version 1.2, an egregious violator of the single core principle of Web Architecture: that resourcs should be addressible by URI and yield representations.
More technically, SOAP required that applications use the HTTP POST verb and send a packet of XML to accomplish any SOAP transaction, even for simple information retrieval. This meant that SOAP-accessible units information and service were not resources and were not, in any meaningful sense, on the Web; they could not be bookmarked, or crawled by a robot, or expedited by a caching proxy.
At that point in history, the "Web" in Web Services was a purely misleading marketing slogan. This mis-step was perhaps best highlighted by Paul Prescod's article Google's Gaffe (see http://www.xml.com/pub/a/2002/04/24/google.html), which told the story of how Google moved its API from a simple URI basis to SOAP, and thus took several large steps backward.
This led to substantial internal dialogue and a few strongly-worded assertions in Webarch, and SOAP 1.2 not only allows but encourages SOAP-packaged online information to be placed on the Web and made first-class citizens.
Web Architecture's insistence that resources are unknowable, that URIs are opaque, and that representation transfer (which may at any time fail) is the only access method has, in practice, worked well. One unfortunate result is that the Web, while rich from a human viewpoint, is a rather barren place from the point of view of software.
Given a URI, here are some questions one might ask about the resource it identifies:
Is it a static HTML page, or the current weather forcast for Oaxaca, Mexico, or a robot which may be controlled by updating the URI, or a video clip of a man confronting a tank in Tienanmin Square?
Who authored that resource? Who maintains it? How often?
Is it appropriate for viewing by children? Who says so?
Does it require the use of a modern standards-compliant browser?
Has it been praised by the Pope, or blocked by the Great Firewall of China, or condemned by Osama Bin Laden?
The Web has no built-in way to answer, or even ask, these questions. Surely this is a shortcoming.
Take it another way. Prior to my first meeting with a company called Heroic Endeavor, Inc., I am pretty confident that if I go to http://www.heroicendeavor.com I will be able to find out some things about its location, ticker symbol, management team, and customers. Why shouldn't I be able to send a simple piece of software to http://data.heroicendeavor.com to harvest those particulars and stick them in my address book for the day of the meeting? The Web today just doesn't do that.
The reason, of course, is that the Web is metadata-starved. There are a host of high-value-add applications waiting to spring into life to automate, enrich, and accelerate the Web if there were only a diet of machine-processable metadata made available to them.
An example, if any were needed, is the recent runaway success of RSS, which has first of all automated the tedium out of the first-thing-in-the-morning surf-around-for-news process, and second has turned the universe of Weblogs from a scattering of solitary soapboxes to a dynamic community that swirls ideas around and is often the first to discover juicy rumors and fatal flaws and causes celebre. RSS, with its single-digit number of compulsory tags and resounding lack of schema-ware and standards committees and the like, is the perfect parable to illustrate how much benefit can be purchased with how little metadata.
Of course, some of the people who want to enrich the Web's diet of metadata refer to this project as "The Semantic Web", but it is questionable whether this is really helpful.
Work on adding metadata to the Web has tended to concentrate around the community that defines and uses RDF (Resource Description Framework), a project that has yet to get a foothold in the market. RDF is highly consistent with Web Architecture in its use of the URI as the universal of identification of anything; and it is easily explained to a newcomer along the lines of "this is a way to make machine-readable assertions about resources; you know, what URIs point at."
The easy explanations stop right about there. RDF descends quickly into a thicket of reification and abstract model theory and hideously ugly syntax that alienates neophytes and regularly confuses initiates. The designers of RDF have failed to meet the key Web-architectural constraint of minimalism: on the evidence, RDF is trying to do too much and needs to be scaled back and refactored until it is easily usable by mere mortals.
The addition of a metadata framework is perhaps the lowest-hanging fruit today in the whole Web arena. It is safe to predict that one way or another, a solution will arrive on the scene, distinguished not only by its use of the Web's naming scheme, but by the Web's self-containment, statelessness, and maximal simplicity.
Finally, it is crystal-clear that one of the most common and important things one does with metadata is interchange it. Since XML is the data-interchange tool par excellence, we can be confident that XML will be at the center of the Web Metadata revolution, when it finally gets around to happening.
As this essay is written, there are several hundred people in the world who devote some or all of their workday and creative energy to the creation of W3C Recommendations.
Unfortunately, a substantial proportion of this time and energy will prove to be wasted, invested in specifications that arrive on the scene with a soggy "thud" and are never widely implemented, or whose arcane complexities are ignored by industry in favor of a widely-implemented more-or-less compliant subset, or which are implemented among the handful of enterprises that can dedicate a hundred or more engineers to the task, only to be bypassed by some quick hack out of a garage in Sacramento or Shanghai or Slovakia.
The technologies that change the face of the Web are those that are in tune with its architecture; they name everything with URIs, they don't try to pretend that the Web can do anything but (sometimes) give you representations of what's out there, they get their work done with self-describing stateless messages, and they are willing to sacrifice the extras to handle the important bits robustly and scalably.
It is difficult to see how Working Groups composed of dozens of representatives of large enterprises with even larger legacy-technology problems can build the kinds of technologies that drive the Web forward. These are problems of civics, of sociology, and of human nature, not of technology. They are, however, problems worth addressing, because everything works better when the playing field is (more or less) level and the rules are (more or less) written down.
Any attempt to say "thank you" to those who are responsible for all the infrastructure I'm writing about quickly spirals into hand-waving in the direction of the W3C and the IETF and ISO and a hundred thousand unsung engineers who solved important little pieces of the big problem.
I shall confine my published gratitude to my spouse and Chairperson, without whom this paper would not have been written, and to the members of the W3C Technical Advisory Group, who have distinguished themselves by their level-headedness, worked hard, and are an all-around decent bunch of people.
  |
Design & Development by deepX Ltd. 2002 |
