Competing Claims and Interaction Types
January 28, 2004
In this week's XML-Deviant column I am continuing my slog through the W3C TAG's Architecture of the World Wide Web (AWWW). In last week's column I examined some of the key issues surrounding the second of the AWWW's key architectural principles, namely, interaction. I will conclude that examination this week. Next week I will consider the final architectural principle, representation.
The More Things Change
I have at least once during my examination of the AWWW suggested that the its running analogy between communication among parties in one context and communication among parties in the context of the Web might be more harmful than helpful. Ambiguity, for example, isn't always a detriment to communication; sometimes it's even an advantage. Ambiguity on the Web is likely not a helpful thing, but it's important to be clear about what kind of ambiguity, ambiguity as to which possibilities, its real costs and benefits, and so on. In AWWW 3.4 Authoritative Representation Metadata the issue of which resource is identified by a URI is raised again:
Successful communication between two parties using a piece of information relies on shared understanding of the meaning of the information. Arbitrary numbers of independent parties can identify and communicate about a Web resource. To give these parties the confidence that they are all talking about the same thing when they refer to "the resource identified by the following URI ..." the design choice for the Web is, in general, that the owner of a resource assigns the authoritative interpretation of representations of the resource.
Now, frankly, it is unclear why this bit of text is in the AWWW at this point. As
the
discussion which follows it makes clear, the issue is what should be done to resolve
clashes
between, for example, the data offered as the representation of a resource and the
server
metadata about that data. For example, what should a user agent do when character
set
encodings don't match or when the format of the representation doesn't match, in some
way,
the Internet Media Type of the HTTP Content-Type field? The principle which is
used to resolve this is a specialization of a more general principle, one which I
discussed
in a previous column ("Reviewing
Web Architecture"): "Silent recovery from error is harmful".
One might point out that, Occam's razor being as keenly edged now as ever, the makers of principles, no less than the makers or catalogers of entities, ought to refrain from propagating them needlessly. Which is just a fancy pants way of saying that it's not clear why the AWWW needs another, very specialized principle in section 3.4.1. ("Inconsistencies Between Metadata and Representation Data") rather than merely applying the more general principle about silent error recovery. I'm assuming, as will all readers of the AWWW, that there is an unstated assumption that doing harm is to be avoided. The AWWW doesn't really need a principle which says "User agents MUST NOT silently ignore authoritative server metadata" when it already has a more general and perfectly applicable principle about avoiding silent recovery from error.
So, the first problem is that we seem to have a case of the needless propagation of principles, that is, a weak violation of the general principle of parsimony. But there is a second problem: since the real issue here is resolved by means of a principle about explicit error recovery, why do we get the curious paragraph, which I quoted earlier in full, about URI ownership? Frankly, I'm a bit perplexed as to the relevance of URI ownership here. The issue is how to resolve clashes between self-claims made by representations and claims made about representations in server metadata (that is, claims made about representations by or in the HTTP protocol).
These clashes are a kind of dilemma. One way in which such clashes could be resolved is, whether by fiat or by analysis, to simply grasp one of the horns and then, well, hold on. The AWWW might have raised the question of authority in order to say that, given a clash between representational data and server or protocol metadata, one simply has to treat the self-claims of representations as authoritative. Or, grasping the IETF's horn, it might have said that one has to treat the protocol's metadata claims about a representation as authoritative. The resolution procedure then becomes something like this: when representational self-claims and server-protocol metadata claims conflict, representational self-claims win. I think such a procedure is probably wrong, but it is simple and easy.
But the AWWW doesn't use the URI ownership principle in this way at all. That makes a certain kind of sense: after all, the clash here isn't between two conflicting claims as to which resource R a URI U identifies. That clash, which is the motivation for the AWWW's natural language analogy claims, is to be resolved -- though I find this deeply unsatisfying -- by saying that U identifies the R which O, U's owner, says it identifies.
The AWWW was crafted -- perhaps this goes without saying -- by a fine group of very experienced web architects. Charity obliges us to assume that this puzzling paragraph about URI ownership is meant to play some constructive role in the discussion about clashing representational and metadata claims. But sometimes reason can't satisfy every obligement of charity; and for me this is one such case.
The More They Change
The next issue with regard to protocol interaction is something the AWWW describes as the distinction between safe and unsafe interactions. It's different from other issues in that it has a much wider scope. Let me explain what I mean.
The Web -- by which I mean here HTTP plus SGML-derived markup languages -- has evolved into a general client-server application framework. Yet the origin of the Web is a publishing medium. The default, built-in web application is and will always be a hypermedia publishing application. As it so happens, this built-in hypermedia publishing framework -- with its dominant metaphor of uniformly-identified, client-requested document qua representation resource passing -- is capable of expressing a wide range of application types. With the advent of the Common Gateway Interface, the Web was firmly on its way to becoming a rich client-server application environment.
This evolution meant that interactions between user agents and origins servers were no longer uniform. Some of those interactions are merely instances of the Web's default publishing application. The only side effect of a typical GET that a human agent cares about is that the user can read another document (since users don't think about the Web in terms of resources and retrieved representation-states but, rather, as a way to read other people's documents). Of course, we have to distinguish between kinds and kinds of obligation for all of this to make any sense at all.
|
|
|
Also in XML-Deviant |
|
When the AWWW says that safe interactions are ones by which human users incur no
new
obligations, what it really means is that some interactions have side effects which
human
users care about -- called "unsafe interactions" -- while other interactions do not
have
side effects which human users care about -- called "safe interactions". I think the
distinction actually lies here, rather than between obligating and non-obligating
interactions for the following reasons. First, human users may be obligated by merely
reading a document. Second, retrieving representations obliges agents to observe,
for
example, all of the MUST NOTs and MUSTs of all of the relevant
standards and specifications documents.
The first case happens as a routine matter of modern life. Reading a subpoena or
a divorce
decree or a political tract or an email from an old lover -- all of these may be
obligation-creating or obligation-incurring acts which are also naturally accomplished
on
the Web by means of "merely" retrieving a representation. And, yes, they are
obligation-implicating in part because they are acts embedded within rich, complex
non-Web
webs of social significance and signification. But then so, too, is the AWWW's canonical
example of a POST incurring a credit card debt. That protocol interaction is
obligation-implicating in part because it is the enactment of a complex commercial
relationship between a lender and a borrower.
This discussion also suggests another distinction: the one between interactions which create (subscribing to a mailing list) and interactions which incur (charging a credit card) obligations. Does the AWWW really mean only incurring interactions? I don't know, but I'll use the phrase "obligation-implicating" from here on since I think both are problematic.
But perhaps the AWWW has some other, restricted sense of obligation in mind? The examples it gives all fall within a kind of restricted range: credit card charges, "subscribing to a newsletter, posting to a list, or modifying a database". (Isn't this last example particularly bad? If a web site logs accesses to a database, then my retrieving a representation modifies a database. But that's clearly not what the AWWW intends.) These are mostly unlike the examples of obligation-implicating acts I offered earlier. But it would be good for the AWWW to have some principled or at least clear way of distinguishing these kinds of obligation.
Second, since the principle here is that "Agents do not incur obligations by retrieving a representation", it's not entirely clear whether the AWWW means human users or user agents (i.e., browsers) or both. The people who program user agents are at least weakly obligated to do so in such a way as to not violate the relevant standards and specifications when retrieving representations. It's a natural, even if anthropomorphizing way of speaking to say that user agents are obliged to follow the relevant standards when retrieving representations.
At the very least, then, there is something useful to be said here about web publishers and web application developers being careful about what sorts of web interactions create side effects that human agents are likely to especially care about. This something is however very hard to state in terms of architectural principles.
The problem here is that belated architectural elucidation is subject to a cruel tension. On the one hand, the Web is in place and it clearly works; but that doesn't necessarily mean it is architecturally or conceptually elegant in all of its parts. It could work better, of course, and there are specific practices to promote or demote so that the Web continues to work. On the other hand, when humans sit down to do something which they call an architecture of a complex system, we have need of conceptual elegance and a certain purity. Gross or even subtle violations of the various conceptual virtues strike us as reasons to think such an architecture could be improved. There is a tension, then, between the Web which is deployed and working and the ideal Web the principles of which the TAG has tried to conceptually elucidate.
Which suggests an obvious conclusion: It's a hard job; someone has to do it; better them than me.