Stuart Lewis
University of Wales, Aberystwyth
29 January 2002
Position Paper for The W3C Workshop on Delivery Context
It is only through using a technology that you can discover its strengths, limitations and problems. This position paper describes the author's experience of implementing web services that make use of CC/PP. It describes:
In light of these experiences, ideas about possible changes needed in the CC/PP protocol may be challenged.
The motivations for using a protocol such as CC/PP are clear. A service provider would like as many possible devices and browsers (thus users) to be able to access their content. This can be for two reasons:
It is motivations such as these that have driven the W3C, the IETF and the WAP Forum to develop protocols that attempt to solve these current limitations with making web services as available and accessible as possible.
Implementations
The author has implemented two systems that make use of CC/PP and UAProf profiles to deliver content in an acceptable manner to any device.
Implementation One - Dissertation
The first implementation was undertaken as a 'proof of concept'
system for a university dissertation [2]. The dissertation looked
at the whole subject of content negotiation and used CC/PP as a possible
enabling technology. The project created a working end to end system that used
CC/PP profiles to deliver relevant content to the browser. The system was Java
Servlet based and made use of Apache Cocoon to process the content.
The content was stored in XML files. Alongside each piece of content was a semantic description of the content (e.g. this part of the XML is the content title, that part is a list of choices etc). Mark-up language description files were also created to store the formatting of a page in that mark-up language (e.g. how to format a list in that language). By using the content, the content description and the language descriptions, XSLT files were dynamically created. These were then applied to the XML content by Cocoon to create the finished page. The system worked and was able to serve content to common desktop browsers, text-only browsers, WAP browsers and a custom browser. The custom browser used the Festival [3] text-to-speech program to provide a lightweight voice browser. A custom mark-up language was developed called FML (Festival Mark-up Language). Using this new language enabled the system to demonstrate how a new class of device can be supported with the addition of only one new file describing its mark-up language.
Implementation
Two - DICE
DICE [4] is a new implementation based on experiences gained from the first
implementation. DICE (Device Independent Content Engine) is an open-source
project that is freely downloadable.
Rather than having to resolve CC/PP profiles and profiles-diffs manually, DICE uses DELI [5] developed at Hewlett Packard Research Laboratories. DICE is again Java Servlet based, and has been designed to provide a framework for developing custom CC/PP compliant web applications and services. It is based around two queues. One queue uses the HTTP request to produce content, while the other queue uses this content, and the resolved profile from DELI to process the content into a suitable form. The queue allows the producing and processing of content to take place over stages. For example the first producer in the queue may produce a page template, whereas subsequent producers in the queue may modify the template to add in information, for example, from a database or external source.
Two sets of producers / processors have been included with the download distribution. The first performs simple page selection. It uses the profile to select the relevant pre-processed page. For example, for a static web site, several versions can be written, one for each class of browser. DICE will give the browser the most relevant version. The second example uses a custom mark-up language. To convert between the custom mark-up language and 'real' mark-up languages, mappings are given in configuration files to map each custom tag to its equivalent in the required mark-up language. The mappings allow the presentation details (e.g. templates) to be added to the content.
Limitations and Problems
Ordering of choices
Currently CC/PP profiles provide unordered lists of elements
(Bag) to indicate a list of options where any of the
options would be acceptable to the browser. Two examples
of this are:
However situations may arise where multiple resources are available from the server: for example when a document is available in both English and French. In such situations it is desirable for the profile to be able to express a preference for one option over another e.g. prefering Welsh to English. In UAProf, this is achieved using the RDF construct for ordered lists of elements (Seq). This approach could also be used in CC/PP.
Excess information
The current specification for CC/PP profiles results in profiles that are
very verbose. In the two implementation mentioned above, only 2 of the
parameters were ever used, those being
While much of the rest of the information may be useful in particular web services, some of the information seems to be irrelevant. For example, why would a server wish to know who the vendor of a browser is? If they have the name of the browser, can the vendor not be derived? Whilst much of the information would be good for collection of very detailed statistics on browser and platform usage, much of the information seems extraneous.
Lack of data
As a web service developer, I would like see the adoption of CC/PP and UAProf as
compatible standards. By using these technologies, the job of a developer of
multiple platforms is made much easier. Unfortunately there seems to be a
'chicken and egg' situation for the adoption of the technology by browser and
server vendors. Until browsers start to broadcast their profiles, servers will
not implement facilities to use these profiles. And until servers implement the
profiles, browser vendors will not add profiles to their browsers.
To kick-start the process, a set of profiles for all current and legacy devices should be created. Mappings between user-agent strings and these profiles will also be required. Having these profiles will allow servers to start being developed to serve relevant content to current browsers. Once this starts to happen, browsers will be more keen to adopt the standards.
Stuart Lewis is a researcher in the Department of Computer Science at the University of Wales, Aberystwyth, Wales, UK. His interest in CC/PP lies from a web service developers point of view. His experience comes from twice having to implement CC/PP compliant services.