Introduction to Device Independence, Part 2

October 6, 2004

Delivery Context Concepts

In the first part of this article about device independence in the Web, I introduced the main principles from three points of view: the user, the author, and the delivery mechanism. When a request is made for a web resource, not only should the request specify the resource identifier, but it also should provide enough information about the access mechanism and the user that the right kind of user experience can be provided.

An important related concept is Delivery Context, which is a set of attributes that characterize the delivery environment. Delivery context information is typically used to provide an appropriate format, styling, or other aspect of some resource representation that will make it suitable for the capabilities of a presentation device. The selection or adaptation required to achieve this may be performed by an origin server, by an intermediary in the delivery path, or by a user agent. In this article we will review existing technologies for representing, conveying, and processing delivery context.

The originator of a request for some content may also specify delivery context information, which can help that request be handled appropriately. In practice, the context information may be included as part of the request, or some or all of it may be supplied indirectly as a reference to information stored separately. After that the response to a request for web content may be adapted, based on the delivery context information available at that point in the delivery chain, to create a modified response. A requestor and adaptor may act together as an element in the delivery path providing a specific part of the adaptation. The requestor may modify the request, including providing new context information, in such a way that the response can be adapted appropriately.

For example, a transcoding proxy may offer to accept a media type not included in the original request. When the response is received by the proxy, that media type is adapted to one that is acceptable to the originator of the request.

In the most general situation, a sequence of requestors may provide additional delivery context information at different points in the request path from client to server. Similarly, a sequence of adaptors may modify the response in the response path between the server and the client. The response may be modified based on any delivery context information available at that point in the response path.

Existing Technologies

1. HTTP.. Currently information on the Web is delivered by HTTP (See RFC 2616). In HTTP 1.1 there are a number of standard accept headers that can be used to match the capabilities of a requesting device, including Accept, Accept-Charset, Accept-Encoding, and Accept-Language. Also there is a User-Agent header that identifies the browser or user agent. There are no standards about how user agent information is constructed. While HTTP headers are currently the most widely used delivery context information, they are difficult to extend and have (particularly in the case of the User-Agent header) freeform values that are difficult to interpret.

2. HTTP Content Negotiation. HTTP 1.1 has a feature called server-driven negotiation. The server selects content based on HTTP header information. It examines a user agent's request headers and determines which alternate representation to send to a user agent. HTTP content negotiation is really a subcase of the HTTP headers approach. It is also possible within HTTP 1.1 to support agent-driven negotiation, in which the user agent is responsible for selecting the most appropriate content representation. The server initially responds with a list of available representations, which then allows the user agent to make another request for the preferred representation. However, this has the disadvantage of introducing additional delay through multiple request-response round trips.

3. Media Queries. HTML4 and CSS currently support media-dependent stylesheets tailored for different media types. Media Queries is another W3C Candidate Recommendation introduced to make style markup conditional on delivery context. For example, a document may use sans-serif fonts when displayed on a screen and serif fonts when printed. A Media Query consists of a media type and one or more expressions to limit the scope of stylesheets. The media features that can be used in media queries include "width," "height," and "color." By using media queries, representations can be tailored to a specific range of output devices without changing the resource itself. Like CSS, media queries are typically expected to be processed directly in user agents, based on local delivery context information. However, they could also be fully or partially processed at servers or intermediaries in the response path, based on delivery context information passed as part of a request for content. A media query can be included in the XHTML or XML document and look like this:

<link rel="stylesheet" type="text/css" 

	media="screen" href="sans-serif.css">

<link rel="stylesheet" type="text/css"

	media="print" href="serif.css">

4. SMIL. Synchronized Multimedia Integration Language (pronounced "smile") is yet another vocabulary for accessing a limited number of device attributes. SMIL 2.0 is defined as a set of markup modules that can be integrated into specific language profiles. In particular, it defines a BasicContentControl Module that describes certain system attributes that may be used to control a SMIL presentation. These attributes may be given dynamic values according to the runtime environment. Like media queries, they allow a user agent that supports dynamic SMIL attributes to access local delivery context information. For example, this SMIL fragment chooses between content written for different screens:


...

 <par>

    <text .../>

    <switch>

       <par systemScreenSize="1024X1280" systemScreenDepth="16">

       ...

       </par>

       <par systemScreenSize="480X640" systemScreenDepth="32">

       ...

       </par> 

       <par systemScreenSize="480X640" systemScreenDepth="16"> 

       ... 

       </par> 

    </switch> 

 </par> 

 ...

5. CC/PP. The W3C has specified a structure for profiles, called CC/PP (Composite Capabilities/ Preferences Profile), based on RDF. This profile structure is vocabulary independent and allows the use of one or more vocabularies that may be optionally described using RDF Schema. A CC/PP profile contains a number of CC/PP attribute names and associated values that are used by a server to determine the most appropriate form of a resource to deliver to a client. It is structured to allow a client to describe its capabilities by reference to a standard profile, accessible to an origin server or other sender of resource data, and a smaller set of features that are in addition to or different than the standard profile. A set of CC/PP attribute names, permissible values, and associated meanings constitute a CC/PP vocabulary. It is interesting that work on its definition and implementation is continuing both in W3C and in the Java Community Process.

CC/PP is an extension of the HTTP protocol. A typical CC/PP-enabled HTTP request looks like this:

GET /path/to/resource HTTP/1.1

Host: xml.com

Opt:  "http://www.w3.org/1999/06/24-CCPPexchange" ; ns=19 

19-Profile: "1-uKhJE/AEeeMzFSejsYshHg=="

19-Profile-Diff-1: <?xml version="1.0"?>

    <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

    xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"

    xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">

    <Description about="http://www.example.com/MyProfile"><ccpp:component>

    <Description about="http://www.example.com/Browser">

    <type resource="http://www.example.com/Schema#BrowserUA" />

    <uaprof:BrowserName>Mozilla</uaprof:BrowserName>

    <uaprof:BrowserVersion>5.0</uaprof:BrowserVersion>

    <uaprof:CcppAccept< <Bag> <li>text/plain</li> <li>text/vnd.wap.wml</li>

    </Bag> </uaprof:CcppAccept> </Description> </ccpp:component>

    </Description> </RDF>

More details and some research on CC/PP is provided by Didier Martin in an XML.com article, How Would You Like That Served?

6. User Agent Profile. The Open Mobile Alliance (formerly the WAP Forum) has defined a User Agent Profile (UAProf) as an implementation of CC/PP for WAP-enabled mobile terminals. WAP defined the WSP protocol, which includes a compressed encoding, for use between the phone and the gateway onto the Internet. WAP 2.0 defines an extension of HTTP 1.1 as an Internet protocol (W-HTTP) that uses custom headers. The WAP Forum has also defined a profile vocabulary that includes assertions regarding the hardware and software characteristics and WAP-specific features of the mobile terminal and associated transport network capabilities.

Implementations

Currently there are two interesting Java implementations of CC/PP and UAProf. The first, DELI, provides an API to allow Java servlets to determine the delivery context of a client device using CC/PP or UAProf. DELI is an open source library developed at HP Labs that allows Java servlets to resolve HTTP requests containing delivery context information from CC/PP- or UAProf-capable devices and query the resolved profile. It also provides support for legacy devices so that the proprietary delivery context descriptions currently used by applications can be replaced by standardized CC/PP descriptions.

The second, more interesting implementation is called SADiC. The Semantic API for the Delivery Context (SADiC) is an innovative Java API for processing and interrogating CC/PP and UAProf profiles, which exploits the ideas of the Semantic Web. SADiC already provides two protocol handlers for use within a J2EE web tier, corresponding to the CC/PP Exchange Protocol over HTTP (CC/PP ex) and the UAProf extension of the Wireless Profiled HTTP (W-HTTP), respectively. Further, SADiC also provides the implementation of a simple servlet filter that leverages these handlers (by means of the generic protocol manager) in order to extract the CC/PP profiles communicated through an HTTP mechanism, and to provide the already processed profile to the servlets or filters following in the processing chain of an HTTP request. The semantic approach of SADiC leverages ontologies in order to achieve semantic convergence between the CC/PP and UAProf specifications. It uses Web Ontology Language (OWL) for describing ontologies.