Roger Gimson
8 February 2002
HP Laboratories, Bristol UK
Email: roger_gimson@hp.com
Position Paper for the W3C Workshop on Delivery Context, 4-5 March 2002
HTTP provides primitive mechanisms for conveying delivery context information from a client to a server. CC/PP provides a framework for conveying a much richer set of information. This position paper lists some of the outstanding issues that remain to be addressed in using delivery context to achieve greater device independence.
Delivery Context, as defined in the Device Independence Principles, is
a set of attributes that characterizes the capabilities of the access mechanism and the preferences of the user
In order to achieve greater device independence when authoring web content, the delivery context attributes of most relevance are those related to device capabilities, or to user presentation preferences. (Delivery context may also be used to convey the application preferences of a user, or other contextual information.)
Though HTTP and CC/PP provide mechanisms for expressing capabilities and preferences, we also need to consider how such information is defined, created, communicated and applied. This is an end-to-end issue, that affects many cooperating elements along the delivery path. Widely accepted solutions are needed at each point before the potential benefits can be achieved. This position paper lists some issues that have not yet been addressed in using delivery context to achieve greater device independence.
Delivery context information may be composed from different sources. For example, within a single client, sources might include the native hardware, the operating system, the browser, installed software components, attached smartcards (e.g. for location sensing or personal identification) and running applications. Methods are required to allow different sources to contribute partial information in building a device profile.
Delivery context information may be decomposed for use by different targets. For example, device adaptation processes may make use of device capabilities and user presentation preferences, while application preferences are separated and passed on to the relevant application.
To assist in composing and decomposing delivery context information, without significant additional processing overhead, it should be possible to allow information from different identified sources and using different vocabularies to be kept separate. It would also allow different parts of the information to be encrypted if necessary for security, such as sending application context between a personal id card and a bank. This could be based on the modularity already supported within CC/PP either at the level of separate profiles (such as suggested for intermediary proxies in the delivery path) or at the level of components within profiles.
Currently there is no standard way of defining a vocabulary for delivery context information in a machine-readable form so that it can be automatically both checked for conformance and resolved. For example, UAProf is defined using RDF schema, but has to resort to comments for attribute types and resolution rules. Attribute types could potentially be defined using XML Schema Datatypes, but some means of expressing resolution rules would also be needed.
It is inevitable that vocabularies will evolve over time. This may lead to redefinition of similar concepts in different vocabularies. Proliferation of different ways of expressing the same information will complicate the use of delivery context information by adaptation processes. It should be accepted practice to extend existing vocabularies when defining a new one. This means that vocabularies can evolve without invalidating previous versions. It also means that new vocabularies can reuse appropriate existing vocabularies for similar attributes. For example, a common vocabulary for defining screen attributes could be used across many kinds of screen-based device, each of which had their own specific extensions.
A simple example device vocabulary is provided in Appendix C of the CC/PP specification, and in the CC/PP Implementors Guide creators of new vocabularies are encouraged to use this rather than define new terms. However, RFC2534, UAProf and the recently published Media Queries have used slightly different definitions for similar attributes. The definition of some well-defined common core vocabularies, along with the extensibility mentioned above, would further encourage reuse and simplify server-side support.
For approaches in which client-side adaptation is handled through media dependent CSS stylesheets, there needs to be an agreed mapping between client-based delivery context information and CSS media queries.
For approaches in which client-side or server-side adaptation is handled through XSLT stylesheets, there needs to be an agreed way for delivery context information to be accessed within XSLT stylesheets, such as through global parameters.
No standard protocol has been defined for conveying CC/PP information in an HTTP request. UAProf uses its own additional HTTP headers (W-HTTP). A standard delivery context protocol is required for HTTP (and perhaps for other protocols such as SOAP).
Only two of the issues raised above require the definition of new standards - vocabulary definition and protocols. The others could be achieved through the widespread adoption of agreed practices for structure, vocabulary and interfacing to external software. The danger is that the very flexibility provided by a framework such as CC/PP may lead to divergent solutions, which will make the goal of greater device independence harder rather than easier to achieve.