Reviewing Web Architecture
December 17, 2003
In last week's XML-Deviant ("The TAG's Town Hall"), filed from the XML Conference 2003 in Philadelphia, I described the town hall meeting held by members of the W3C's Technical Architecture Group (TAG). The chief purpose of the town hall was to announce that one of the TAG's primary bits of work product, Architecture of the World Wide Web (AWWW), had entered the Last Call phase.
In that column I exhorted technically-minded people, or at least all those who care about the Web and its future, to read and critically reflect upon AWWW, because the TAG has requested such feedback and the document itself covers an interesting set of issues. For the ambitious among us, the AWWW's change history also makes for interesting reading.
Another way to put the same point is to say that it's hard for me to imagine someone who is interested in the Web, in a deep and technical way, but not interested in a document which purports to be the first rigorous elucidation of the architectural principles, and their associated good practices, of the Web itself. If there are such people, I'd be interested in hearing from them.
I'd also be interested in hearing about prior art; while I'm fully prepared to credit the TAG's claims that AWWW is the first rigorous elucidation of the Web's architecture, I'm very interested in antecedent documents or conversations which I don't yet know about. I know about Tim Berners-Lee's various skunkworks documents and about Roy Fielding's dissertation, which spawned the REST movement; but that's about it. If you know of interesting antecedents, feel free to email me -- they'll form the ground of future columns. Note that I'm not as interested in architectural discussions of pre-Web or Web-like systems as much as discussion or documents of the architecture of the Web itself.
Thus, in an effort to eat my own tech-pundit dog food, I want to offer some feedback on the AWWW in what remains of this column.
Architectural Building Blocks
As the AWWW puts it, the architecture of the web is based upon three concepts, each of which is related to the idea of a resource: identification of, interaction with, and representation of resources. Since, as we know from the REST position, the web is an information space within which agents have access to various representations of the state of various resources, it makes sense to orient the building blocks of the web's architecture around the idea of a resource. These concepts correspond, of course, with particular technologies, like URIs (the means of resource identification), the HTTP protocol (the means of agent-resource interaction), and various representation languages, like HTML, XML, RDF, etc. (the means of resource representation).
What Is, What Can Be A Resource?
In a previous column I suggested that an earlier draft of AWWW had a problem insofar as it relied upon RFC 2396's notion of what a resource is. RFC 2396, as you may recall, says that a resource is anything that has identity, which is to say that a resource is anything whatever. That's not a very helpful definition, since it provides no traction by which one might distinguish between the set of things which are resources and the set of things which aren't. Definitions which provide no such traction are not really definitions at all.
AWWW, however, now relies upon the "IETF Internet Draft draft-fielding-uri-rfc2396bis-03", rather than RFC 2396, which it is expected to obsolete at some point. Roy Fielding's revision (though both Tim Berners-Lee and Larry Masinter are listed as authors, I gather that Fielding is the prime mover here) of RFC 2396 drops the talk of identity, suggesting instead that a resource is "anything that can be named or described".
So, things which cannot be described or named cannot be objects within the web as a representational system. Two qualifications follow directly: resources don't have to be "necessarily accessible via the internet" and "abstract concepts can be resources". I'm not sure that this is an improvement; but it may not matter since AWWW itself drops most of the particularly conceptual language about resources -- a move I count as prudent.
The Running Example
The authors of AWWW use, as a running example throughout, an interaction between an agent, in this case a natural person named Nadia, and a web resource, a weather report for Oaxaca, Mexico. The resource has a URI, http://weather.example.com/oaxaca, and interacting with that resource via that URI, by means of HTTP and, specifically, a GET, allows Nadia to retrieve a representation of the state of that resource, in this case a resource-representation identified by an internet media type as "application/xhtml+xml".
That's an interesting and simple scenario, and I suspect that it was chosen with due care. Since the resource, the weather in Oaxaca, Mexico, is one which is temporally variable, when an agent interacts with a representation of that resource, the agent is very obviously interacting with a representation of the state of that resource at the time it's requested. It is clear that the weather report of a particular locale has both a constant and a variable aspect; it's constant in that it's always the weather report of that locale, and it's variable in that it's always a report of the weather of that locale, which is something that changes over time. (Yes, there are some locales which have a constant microclimate, but that's a special case which won't detain us here!)
Thus Nadia's interactions with this resource illustrate nicely the interaction between the nature of a resource, which can have both constant and variable aspects, and the particular bits of web architecture and protocol that are appropriate to that nature.
General Principles
AWWW offers four general principles which are common to the web-specific bits: orthogonality, extensibility, error handling, and protocol-based interoperability (about which I will say nothing).
As to the first, orthogonality, it applies both to concepts and to specifications. It can be expressed as a variant of Occam's Razor: Do not needless multiply dependencies among the parts of a system. In other words, loose coupling is good. Let's return to the weather report for Oaxaca. Nadia needs only know the URI which identifies that resource; the URI need not (ought not, really) include the specific representational format of that resource. That is, identification and representation are orthogonal.
This seemingly conceptual point has massive practical implications, including the fact that if you decouple the way you name your web resources from the representational formats with which you describe their states, then you can change those formats in a fairly willy-nilly way. Obviously, the Internet media type has to change, as part of the interaction between agent and origin server, but that change is independent of the URI and, thus, the identification mechanism of resources. Willy-nilly change is an exceedingly useful thing to be able to do, and the vast majority of publishers on the Web get it wrong. This general failure to get it right doesn't cripple the Web, but it does raise the costs, to both producers and consumers, of system change.
The Web's architecture includes some violations of the orthogonality principle, including: HTML's weak extension of HTTP by allowing URI query strings; HTML's extension of HTTP header specifications via META; the ill-specified interaction between the http-equiv META in HTML and HTTP's Content-Type header. In each of these cases the system's dominant representation format, HTML, is allowed to change the system's dominant interaction means, HTTP, in ways which break loose coupling.
I'm not going to say much about the second general principle, extensibility, given that XML.com published a long piece about it recently (more specifically, about managing change in XML vocabularies: "Versioning XML Vocabularies"). I merely want to point out that there is a relation between these two general principles. You promote loose coupling and orthogonality in order to achieve, among other things, extensibility. Or rather in order to avoid blocking it. The designers, caretakers, and implementers may be hampered in their attempts to extend HTTP given that the orthogonality principle is violated by HTML's mucking about with various protocol interaction details.
The third general principle, which concerns error handling, is interesting in at least one sense. The principle is that agents should not recover from errors silently, that is, without notifying the human user. The argument is that, since artificial agents are supposed to act on the behalf of natural persons, "[u]ser agents that correct errors without the consent of the user are not acting on the user's behalf". I think this is, at least, underdescribed.
There is a crucial assumption, that the only way a user agent can act on my behalf is with my explicitly-given consent, that is assumed, rather than argued for. I can imagine a class of web users who have no interest whatever in "understand[ing] the nature of errors," as AWWW puts it. On the contrary, these users might think an agent acted on their behalf precisely by not notifying them of errors and then doing the right thing in response to those errors. That is, the human judgment about what it means for an agent to act on one's behalf is as likely to be as context-dependent and interest-relative as most, if not all other human judgments. What may well seem like acting on my behalf may seem to someone else like meddlesome peskiness.
|
|
|
Also in XML-Deviant |
|
I would amend this principle to say, rather, that silent recovery from error is harmful if, but only if, the silent recovery is not what the natural person in question would have wanted had she or he been notified. Or, put another way, that silent recover is harmful if it's harmful beyond mere failure to notify. There are some errors, or so I assume, that some users may never want to be notified of. Put this way, developers of agents may chose to ask the human user to say, in advance, how certain errors should be resolved, such that the user doesn't have to consent explicitly each time. And, yes, that's a way of giving consent to a type of error, rather than to each error token, but I don't see any problem with that.
Conclusions
In the next two or three installments of this column I will continue to discuss the three fundamental parts -- identification, interaction, representation (called, for reasons unclear to me, "data formats" in the AWWW's table of contents) -- of the Web's architecture in greater detail, paying careful attention both to principles and their practices.