XML News from Tuesday, November 14, 2006

The W3C Technical Architecture Group (TAG) has published On Linking Alternative Formats To Enable Discovery And Publishing. The problem is:

Content creators wishing to publish multiple versions of a given resource on the Web face a number of questions with respect to how such URIs are created, published and discovered. Questions include:

This document explores the issues that arise in this context, and attempts to define best practices that help:

The suggested solution is:

  1. Create representation-specific URIs (specific resources) for each available alternative (representation_i), e.g., http://example.com/ubiquity/resource/representation_i.

  2. If no content negotiation is in place, serve a canonical representation (generic resource) of the content at http://example.com/ubiquity/resource

  3. With that same URI, use HTTP content-negotiation, along with the correct HTTP VARY headers to serve up the appropriate representation at access time. Ensure that the VARY headers capture the right parameters that were used to choose the representation that is being served — this is important for correct behavior when using cacheing proxies.

  4. As an alternative to the previous step, arrange for the server to generate an HTTP 302 (Found) redirect to automatically serve up http://example.com/ubiquity/representation_i when http://example.com/ubiquity is accessed by user-agent_i. This form of redirect involves an extra client/server round-trip, and may therefore be suboptimal for mobile devices. This is a temporary redirect; the accessing user-agent should continue to use the canonical URI when creating bookmarks, or emailing URI. Finally, note that to optimize link traversal out of the resulting document, the content provider might wish to rewrite relative links to point at the specific resource. This will ensure that later uses of the URI results in expected end-user results; e.g., In the following scenario:

    Cell-phone user emails link
    Recipiant opens message on a desktop
    Clicks on the link

    The user following the link from inside the email message on a desktop browser should receive the desktop version, and not the mobile version. Notice that passing around the canonical URI is critical in achieving this behavior.

    Additionally, contrast this solution with using HTTP content-negotiation with VARY headers; using a redirect to the URI as a specific resource has the advantage of freezing all parameters that were used to choose that representation into the URI.

  5. Use linking mechanisms provided by the representation being served to create links to the other available representations. As an example, when using HTML, one might use a and link elements to advertize the availability of alternate representations. In this context, note that there are two distinct types of such links:

    Links for human consumption that are to be presented to the user
    And links for machine consumption, that are used by the user agent to provide additional functionality.

    As an example, links to available alternatives meant for human consumption might use the HTML a element since these are rendered by user-agents. In contrast, links meant for use by bots might use the HTML link element — as an example, this reflects present practice when publishing pointers to Atom/RSS feeds.

    In either case, notice that following these steps creates a mini-graph comprising of the canonical URI and URIs for its various representations.

This is actually just the solution suggested for one particular use case, but the others are very similar.

This seems wise, and in general points out something I've noticed in designing RESTful systems. The server maintainer needs to be able to freely define resources and invent URLs pointing to those resources. A given resource can have more than one URL, and indeed different parts of one document may be individual resources with their own unique URLs. For example, this page could have one URL (http://www.cafeconleche.org/) and every news item on the page could have its own URL (http://www.cafeconleche.org/news/November_14_2006_35156, http://www.cafeconleche.org/news/November_14_2006_34857). Parts of the page could be updated by PUTting the relevant content to the individual item URLs.

Of course this requires an additional layer of indirection on the server, maybe more than one. The current static file system that serves Cafe con Leche can't really handle this. However fewer and fewer sites are generated out of static files these days anyway. The key is to design the server side systems such that URLs are freely created for everything of interest.

I'm reminded of a problem a lot of my intro to Java students have. They can't figure out how to make two objects talk to each other (often action listeners and the applet they're responding to) so they want to put everything in one class. The proper solution to this problem is to add methods to one or the other of the two classes so the objects can communicate. In the RESTful world of HTTP, when you find you're having trouble sending the server the message you want to send it, the solution is definitely not adding a new method. Rather it's adding a new URI. Don't be afraid of URIs. A good RESTful system will have lots of them.

The W3C Privacy Activity has released the final version of the Platform for Privacy Preferences 1.1 (P3P1.1) Specification as a note, not a recommendation, because "The P3P Specification Working Group is lacking the necessary support from implementers to carry on through the Recommendation Process. Therefor the Working Group decided to publish the current P3P 1.1 Specification as a Working Group Note after a successful Last Call." New features in P3P 1.1 include a mechanism to name and group statements together so user agents can organize the summary display of those policies and a generic means of binding P3P Policies to arbitrary XML to support XForms, WSDL, and other XML applications.