Menu

Web Architecture Review: Representation

February 4, 2004

Kendall Grant Clark

In the previous five XML-Deviant columns I've been examining in some detail, the text of the W3C TAG's Architecture of the World Wide Web (AWWW). By turns I have tried to understand, amplify, explain, and criticize this document because it is unique and uniquely deserving of such attention.

So far the Web has been more developed than theorized or conceptualized. And that's a good thing. But if the Web is going to keep evolving, especially in those directions which we call "Semantic Web" and "Web Services", then we -- the development communities that care most about the Web and XML -- need some conceptual explanation or theory of the architecture of the Web. The AWWW isn't unique because it's a conceptualization of a complex system. No, it's unique because it's the only rigorous, comprehensive conceptualization of the Web thus attempted by a standards body.

In this column I shall examine the third of the three key architectural principles of the AWWW, which it calls "data formats" but which I choose to call "representation", following the first two principles, identification and interaction.

Re-presenting Resources

Let's review. The three key architectural principles of the AWWW (and, thus, if the AWWW is right, of the Web itself) are identification, interaction, and representation for reasons best expressed in the REST elucidation of the Web's architectural style. According to REST, the Web is a system in which user agents interact with resources, which are identified by URIs, indirectly by retrieving representations of the state of those resources. In that sense, as an information-system encompassing information system, the Web does rough and tumble trade in representations of resources.

Representations of resource states are typed, and their type is given by their data format. The AWWW puts this point a slightly different way by saying that "a data format ... specifies the interpretation of representation data" -- true enough, if we read "data format" in a very loose way. One of the flexibilities and thus one of the extensibilities of the Web is that it is formally impartial as to data formats. HTML is and will likely always be king, but there is nothing about the architecture of the Web which dictates that any particular data format be used or not used to constitute representations of resource-states. (In case you needed explicit grounds for my claim about the kingship of HTML, consider this: is there another data format which allows you to set details of the underlying HTTP protocol? I can't think of another one.)

That formal impartiality, however, is a bit misleading in one sense. The W3C, as the institution most responsible for the Web and for XML, has a very definite bias toward textual formats -- a bias, I should point out, which is continuous with the IETF, with the RFC canon, and with the history of the Internet generally. (It's interesting to think about this historical preference for textual over against binary data formats in the context of the growing clamor for the W3C to do something regarding binary variants of XML. See Robin Berjon's "Binary Waltz, Play On" and my "Binary Killed the XML Star?".)

"In principle," the AWWW assures us, "all data can be represented using textual formats". Well, sure, just as in principle all data can be represented by binary formats. I don't think this question is one which concerns what is possible in principle but rather what is, in fact, efficient, economical, easy, and, crucially, for whom? As the AWWW says, "the trade-offs between binary and textual data formats are complex and application-dependent". But, in addition to the weight of historical tradition constituted by the IETF, we're talking here about a document produced by the institution, the W3C, which developed XML, probably the most wildly successful, high-level textual data format ever. Thus it should surprise no one that the AWWW throws in a bit of textual-format boosterism:

Textual formats are usually more portable and interoperable. Textual formats also have the considerable advantage that they can be directly read and understood by human beings. This can simplify the tasks of creating and maintaining software, and allow the direct intervention of humans in the processing chain without recourse to tools more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats (the "view source" effect).

One interesting implication here, which I can't help but seeing as an important shift, is that the Web is only a web because it is, in fact, a distributed, decentralized, hypermedia or hypertext information system. This means, among many other things, that it's an information system the resources of which are linked together and, so, an information system which one interacts with by means of following the links between resources.

In that sense, some architectural priority ought to be given to data formats, whether textual or binary, that provide linking mechanisms, such that resource-states represented by those data formats are able to be first class nodes in the web-like network. Given an earlier, fundamental principle of the Web, that important resources should be given a URI, it follows that data formats which promote linking and traversal to other resources are to be preferred to those which do not. We shall have further occasion to discuss this issue further in the next column, when I examine section 4.4. Hypertext.

The Daily Care and Feeding of Representations

Representations of resource states on the Web, as concretized by particular data formats, are meant to be consumed by agents, both human and machine, in a mutually beneficial way. In other words, for any representational system to work, its producers and consumers have to hold in common first and higher-order expectations about their own behavior and about the expectations and behavior of the others.

This general coordination problem -- which the late, very fine philosopher David Lewis understood to be the crux of the problem of convention -- exists no less for the Web than for any other information system. On the Web, which is both distributed and relatively decentralized, this coordination problem often gets expressed as the problem of backward and forward compatibility across versions of particular data formats. The AWWW addresses this very complex issue in section 4.2. Versioning and Extensibility.

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

This general problem of coordination is exacerbated in the context of the Web for at least two reasons: first, the Web is a representational system mediated by machines; second, the Web is a distributed, decentralized system. Natural languages and forms of human sociality have mutually evolved such that the slow drift of the details of particular conventions is compensated for gradually. Language changes social form which informs language which reinforces and communicates social change.

But we moderns, with our mediating machines and our addictions to speed and to change, have to think very hard about the specific coordination problems introduced by new systems like the Web. "Extensibility and versioning," the AWWW says, "are strategies to help manage the natural evolution of information on the Web and technologies used to represent that information." Just so.

Since versioning and extensibility are subjects worthy of deep, sustained, and serious thought, I won't pretend to say anything useful about them here. I will, however, restate the good practices that the AWWW commends. First, data formats should include ways to state explicitly their version information. Second, XML namespace policies should be documented publicly and explicitly. Third, data formats should be freely extensible in ways which do not harm conformance. Fourth, data formats should specify the behavior of consumers when confronted with unknown extensions (the most common such specifications are "must ignore" and "must understand").

In the next, final article of this series, I will examine the remaining issues concerning the last key architectural principle of the Web: "Separation of Content, Presentation, and Interaction", "Hypertext", and "XML-Based Data Formats".