Menu

Reviewing Web Architecture: Conclusions

February 11, 2004

Kendall Grant Clark

In this seventh and final installment of my series of XML-Deviant columns about the W3C TAG's Architecture of the World Wide Web (AWWW) document, I conclude my examination of the third key architectural principle, data formats, which I have been calling "representation".

What is left be discussed of the representation principle includes some core ideas and practices, certainly well-known to the XML programmer community: separation of content and presentation, hypertext, and a grab bag of XML-specific issues.

Separation of Concerns and Interests

The AWWW claims that it is good practice to "design formats that allow authors to separate content from presentation and interaction concerns". I find this recommendation interesting for a few reasons, particularly because of its relative belatedness. HTML, still the most important data format of the Web, is infamous for breaking this practice. In fact HTML 1.0, which Tim Berners-Lee designed, contained a few violations of this practice:

  1. the TITLE element "should ideally fit on one line";
  2. the PLAINTEXT element was "designed to be represented in the same way as example XMP text, with fixed width charater [sic.] and significant line breaks" (even though "[i]ts presence is an optimisation").
  3. the LISTING element, as specified, is chock-full of presentational bits:
    1. it "allow[s] text of fixed-width characters"
    2. "to be embedded absolutely as is into the document";
    3. it's character data should be "portrayed in a fixed width font", such that its source document, whitespace formatting is preserved when displayed;
    4. it "is portrayed so that at least 132 characters will fit on a line".
  4. the ADDRESS element "is italic and/or right justified or indented";
  5. the HIGHLIGHTING element (which I didn't know about till writing this column...) marked "highlighted phrases" but did not, oddly enough, come with a presentational specification or suggestion;
  6. the LIST elements, ordered and unordered, could be displayed, respectively, as "a sequence of numbered paragraphs" or as "bulleted list[s]".

In other words, there's been a lot of presentational concern in HTML specifications from the very earliest days of the Web. What does that mean? Aren't I just being unfair to Sir Tim? Well, not really: the point here is that, first, separating content from presentation is hard; second, that sometimes it's not possible, since presentation is content; third, if this practice is descriptive of the architecture of the Web, I'm hard pressed to see how that can be taken in any robust way, given how often it's been violated. And, I should point out, HTML's ability to break the representation-interaction distinction, by mucking about with HTTP protocol bits, is probably even more problematic. I would have done things differently.

First, I would have formulated this issue explicitly as a forward-looking, prescriptive principle, not as a practice. I would have modulated language like this: "It is good practice for authors to create content that can reach the widest possible audience including users with graphical desktop computers, hand-held devices and cell phones, users with disabilities who may require speech synthesizers, and devices not yet imagined". That describes an ideal towards which many designers and content creators ought to strive, when the ideal is aligned with their explicit goals and projects.

But not every usage of the Web is drive by goals or projects which require the widest possible accessibility by the greatest number of people and devices. Many web applications and web sites are focused on a much narrower set of concerns, including limited communication with a very small subset of all web users. The AWWW concedes this point when it says that "it may not always be desirable to reach the widest possible audience." Yes, exactly: I suspect it's not even the common case to cast one's net as widely as possible. That sensible concession to reality seems not to have made a whit of difference to the formulation of this particular idea. It is simply a fact that I do not care about many (perhaps most) web resources: they are simply addressed specifically to a subset of web users of which I am not a member.

That's just fine. Most messages are not addressed to everyone. That's exactly what one should expect and, thus, allow for architecturally.

Second, I would have addressed it to developers, not language designers. Playing the role of someone conceptualizing the architecture of the Web, I don't really care what language designers do or fail to do; sometimes presentation and content belong together in a data format. What I care about, however, is what kind of data formats get widely deployed on the Web, perhaps especially in Service Oriented Architecture or Semantic Web contexts.

Last, I would have explicitly conceded that in some domain areas -- for example, in many governmental and legislative contexts, as I discussed in "Taking the Pulse of XML Editing" -- presentation and content are not separable, which is to say: sometimes, perhaps often, presentation just is semantics. If the Web is going to be the servant of human concerns, rather than their master, it just has to deal with that fact. In fact, it has always dealt with this fact by being more pragmatic than pure about this context-relative, interest-specific distinction.

When You Click Upon a Link, Makes No Difference What You Think

Ah, finally, in a document purporting to express the principles of the Web, a distributed, decentralized hypertext or hypermedia information system, we come to a section about hypertext... Okay, perhaps I'm being unfairly snarky, but I am surprised that linking gets what seems to be to be such short shrift.

So what does the AWWW say about linking, which it rightly calls "a defining characteristic of the Web"? It says roughly four things to "language designers":

  1. Good representation types allow users to make links to other resources and to parts of representation-states of resources.
    Unhappily, the precise language, which I am paraphrasing here, of "Good practice: Link mechanisms" is out of phase with the AWWW's very problematic discussion of the semantics of fragment identifiers.
  2. Good representation types allow users to make "Web-wide" links rather than merely "internal document" links.
    Isn't that what the previous practice says? A link to "other resources" just is a link to something else on the Web. In other words, the only reasonable reading of (1) is that data formats that allow links to other resources and to parts of representation-states are better than ones that don't, while the only reasonable reading of (2) is that data formats should allow links to resources on the Web and not just to parts of representation-states. Uh, yeah, didn't you just say that? And, if not, it seems that (2) is entailed by (1), so we really only need (1). If not, then (1) or (2) or both need to be refined or sharpened, such that there are other reasonable readings.
  3. Good representation types allow users to make links to many different types of resources, not just resources on the Web.
    Yes. That's an implication of the claim that the Web is an information system which encompasses information systems. Good.
  4. Good representation types allow users to make hypertext links when "hypertext is the expected user interface paradigm".
    Surely the AWWW also wants to say that for those kinds of web application -- Service Oriented Architecture and Semantic Web being the two obvious examples -- where hypertext is not the "expected user interface paradigm", by virtue of the fact that there really isn't a UI per se, one still wants to prefer representation types which allow users to make hypertext links between resources. REST and SOAP and RDF and WSDL and a lot of other fun stuff works precisely because, even in the absence of any human-facing UI, what's happening is that messages are being passed around between machines, messages which contain hypertext links to other resources.

    The real problem here is that there is no real formalization of "hypertext link" in the AWWW. If it means a href links, then my point about SOA and Semantic Web exceptions to this practice is unmotivated and null. But if, as seems likely from Section 4.5.2. Links in XML, "hypertext links" encompasses any link mechanism (that is, XLink and friends) whereby HTTP URIs identify resources with which agents may interact with the resources-states thereof, then something like my point is needed.

My Old Friend, XML

My first reaction to 4.5. XML-Based Data Formats is that every corner case isn't worth including in a statement of the conceptual architecture of the Web, though that's almost certainly a function of my weariness with some of these issues. For example, the use of XML namespaces is clearly an architectural good practice issue. But there is nothing particularly new here, at least not for grizzled veterans of the Namespace Wars.

The XML-Based Data Formats section reads like a grab bag of the venerable permathreads of the XML development community: XML linking, XML namespaces, namespace documents, qnames, and so on. Where the TAG has issued some resolution of these issues, or parts thereof, that resolution has often been covered on XML.com, often in one or more XML-Deviant columns. Therefore, I'm not very motivated here to repeat much of that discussion.

I will, however, make a few comments. First, I appreciate the concession that XML is not always the ideal choice for a data format, even if it is a very subtle concession. (See Section 4.5.1. When to Use and XML-Based Format.) Further, the six "design constraints" for choosing to use or not use XML is worth serious consideration. Second, while the AWWW rightly points out that there is no real consensus about what kind of representation should be retrieved when one dereferences a namespace URI, it does assume that namespace URIs should be dereferenceable, and that the retrieved representation should contain "material for people to read and material optimized for software agents". Third, the AWWW offers two good practices regarding qnames: (1) "Specifications that use QNames to represent URI/local-name pairs SHOULD NOT allow both forms in attribute values or element content where they would be indistinguishable"; and (2) "Language designers who use QNames as identifiers of Web resources MUST provide a mapping to URIs".

What's Next?

Also in XML-Deviant

The More Things Change

Agile XML

Composition

Apple Watch

Life After Ajax?

I started out this series of columns, back in December at the XML conference in Philadelphia, because most of the TAG -- Sir Tim being the most notable absentee -- held a Town Meeting at which they asked for feedback from various communities on the AWWW document. I thought and still think that the first explicit attempt to formulate an architecture for the Web is an effort which deserves robust, critical analysis from those of us who care about such things.

I also, speaking personally, started this series of columns because I'm working on a book for O'Reilly about REST Web Services. Any such book needs, at least in my estimation, a clear exposition of the theory of the Web, particularly the ideas about the Web formalized in the REST architectural style. The AWWW is, as I hope I have made clear over the course of these columns, deeply indebted to Roy Fielding and to his REST ideas.

By way of concluding this series, I'd like to encourage any and all of you who care about the Web, service-oriented architectures, web services, or the Semantic Web to give the AWWW a careful reading. Even if you concentrate only on one of its key parts -- whether resource identification, agent interaction, or resource-state representation -- you will have done yourself and your community a service. The TAG is taking comments about the AWWW until 5 March 2004, so you still have plenty of time.