In order for a web server to provide optimized content to different clients it requires a description of the capabilities of the client. Two new compatible standards have been created for describing delivery context based on the Resource Description Framework (RDF): Composite Capabilities / Preferences Profile (CC/PP) created by the W3C and User Agent Profile (UAProf) created by the WAP Forum. These standards allow the efficient transmission of delivery context information to the server even via low bandwidth wireless networks. Instead of sending an entire profile with every request, a client only sends a reference to a profile, stored on a third device known as a profile repository, along with a list of differences specific to this particular client. The process of reassembling the final profile from the profile references and differences is known as profile resolution.
HP Labs has produced an open-source library called DELI that allows Java servlets to resolve HTTP requests containing CC/PP or UAProf information and query the resolved profile. This document describes how DELI may be used within Apache Cocoon. For more information on the DELI library please refer to the DELI web-site. DELI currently uses Jena, an RDF Framework developed at HP Labs. For more details of Jena see Brian McBride's paper and the HP Labs Semantic Web activity homepage.
CC/PP is described in CC/PP Structure and Vocabularies, CC/PP Requirements and Architecture and CC/PP Terminology and Abbreviations. A CC/PP profile is broadly constructed as a two level hierarchy: a profile has a number of components and each component has a number of attributes. A proposed (and largely deprecated) protocol for CC/PP is described in CC/PP exchange protocol using HTTP extension framework and Content Negotiation Header in HTTP Scenarios. The protocol work has been deprecated because the CC/PP Working Group was not chartered by the W3C to do protocol work. In addition this protocol uses HTTP-ex which means it is incompatible with existing HTTP web servers. Therefore it is suggested that people requiring CC/PP functionality should use the W-HTTP protocol used by UAProf. This has identical functionality to the deprecated CC/PP protocol based on HTTP-ex, but will work with existing HTTP servers. Hopefully when the CC/PP Working Group is recharted to work on protocols, it will propose a protocol compatible with HTTP/1.1 similar to W-HTTP.
The UAProf specification is based on the CC/PP specification. Like CC/PP, a UAProf profile is a two level hierarchy composed of components and attributes. Unlike CC/PP, the UAProf specification also proposes a vocabulary - a specific set of components and attributes - to describe the next generation of WAP phones. The specification also describes two protocols for transmitting the profile from the client to the server. Currently DELI only supports one of the UAProf protocols, as the other is based on HTTP-ex so is incompatible with existing web servers.
Profiles using the UAProf vocabulary consist of six components: HardwarePlatform, SoftwarePlatform, NetworkCharacteristics, BrowserUA, WapCharacteristics and PushCharacteristics. These components contain attributes. In DELI each attribute has a distinct name and has an associated collection type, attribute type and resolution rule. In UAProf there are three collection types:
Simple contains a single value e.g. ColorCapable in HardwarePlatform. Bag contains multiple unordered values e.g. BluetoothProfile in the
HardwarePlatform component.Seq contains multiple ordered values e.g. Ccpp-AcceptLanguage
in the SoftwarePlatform component.In addition attributes can have one of four attribute types:
String e.g. BrowserName in BrowserUA.Boolean e.g. ColorCapable in HardwarePlatform.Number is a positive integer e.g. BitsPerPixel in HardwarePlatform.Dimension is a pair of positive integers e.g. ScreenSize in HardwarePlatform.Finally attributes are associated with a resolution rule:
Locked indicates the final value of an attribute is the first
occurrence of the attribute outside the default description block.Override indicates the final value of an attribute is the last occurrence
of the attribute outside the default description block.Append indicates the final value of the attribute is the
list of all occurrences of the attribute outside the default
description block.The UAProf vocabulary is described using the file uaprofspec.xml.
This describes the attribute name, component,
collectionType, attributeType and resolution rule of each component.
The vocabulary description file has the following format:
An example W-HTTP request using this protocol is shown below:
The first two lines describe the resource that is being requested by the client, http://localhost/ccpp/html, and the method being used to make the request, GET, and the protocol being used HTTP/1.1. The remaining lines of the request describe the device delivery context. This is specified using a profile reference and a profile-diff. The profile is referenced via the x-wap-profile line and has the URI
After the profile reference, there is a value
known as a profile-diff digest. The first part of the profile-diff-digest, 1-, is the profile-diff sequence number. This is used to indicate the order of the profile-diffs and to indicate which profile-diff the profile-diff digest refers to. The remainder of the profile-diff digest is generated by applying the MD5 message digest algorithm and Base64 algorithm to the corresponding profile-diff. The MD5 algorithm takes as input a message of arbitary length and produces as output a 128-bit "fingerprint" or "message-digest" of the input. The Base64 algorithm takes as input arbitary binary data and produces as output printable encoding data.
After the profile-diff digest, the next line contains the x-wap-profile-diff. This request header field also has a profile-diff sequence number which indicates that this profile-diff corresponds to the previous profile-diff-digest. The profile-diff itself consists of the XML fragment which spans the remainder of the request. Multi-line request header fields are permitted by the HTTP/1.1 specification as long as each subsequent line starts with either a tab character or a whitespace.
When the server receives a HTTP request with UAProf request headers, it has to perform profile resolution i.e. retrieve the referenced profile(s) and any further profiles referenced via default blocks. It then has to merge these profiles and the profile-diffs while applying the UAProf resolution rules.
In order to use DELI, you need to enable the DELI component.
In addition, you may want to configure DELI using deliCocoonConfig.xml, the DELI
configuration file or legacyDevices.xml, the
DELI legacy device support file.
In order to use DELI you need to specify
the configuration file and set the use-deli parameter to true. You can either
do this in deli.xconf in which case you will need to rebuild
Cocoon or change the deployed cocoon.xconf in the web-server directory:
The file sitemap.xmap is already configured to provide a TraxTransformer for
use with DELI called xslt-deli:
DELI also has its own configuration file has the following format:
This file can contain a number of configuration directives described in in the following sections:
The caching options control how the server caches referenced profiles. DELI can either cache profiles indefinitely or update stale profiles after a set interval. It is also possible to configure the maximum size of the profile cache.
| Element Name | Default Value | Description |
|---|---|---|
| maxCachedProfileLifetime | 24 hours | The maximum lifetime of a cached profile in hours. |
| maxCacheSize | 100 | The maximum number of profiles in the profile cache. |
| refreshStaleProfiles | false | Do we refresh cached profiles after the maximum lifetime has expired? |
The debugging options are used to control the information that DELI prints to the Servlet engine console.
| Element Name | Default Value | Description |
|---|---|---|
| debug | true | Is the automatic debug log information turned on? |
| printDefaults | true | Print both default and override values of attributes for debugging purposes? |
| printProfileBeforeMerge | false | Print the profile before merging for debugging purposes? |
As already mentioned DELI can support legacy devices by recognising the user-agent string supplied by a client and mapping it on to a profile. In order to use this facility it is necessary to supply an XML file that contains information about legacy device user-agent strings and the corresponding profile URLs. The format for the legacy device file is described in a subsequent section.
| Element Name | Default Value | Description |
|---|---|---|
| supportLegacyDevices | true | Is the legacy device database turned on? |
| legacyDeviceFile | legacyDevice.xml | The file containing the legacy device database. |
It is possible to switch on whitespace normalisation in profile-diffs prior to calculating the profile-diff-digest so that additional whitespaces added by the proxy are ignored. To use this option clients must also support whitespace normalisation.
| Element Name | Default Value | Description |
|---|---|---|
| normaliseWhitespaceInProfileDiff | true | Is whitespace normalisation of the profile-diff prior to calculating the profile-diff-digest turned on? |
DELI has a number of vocabulary options. Firstly it is possible to configure the vocabulary using an XML file. Secondly it is possible to specify the URI to be used for the RDF namespace and the CC/PP or UAProf namespace. This is important because as the specifications are revised they adopt new namespaces. Thirdly it is possible to set the string used to represent components and defaults in the vocabulary. This is important because the two standards currently use different cases for the first letter of default elements (CC/PP uses "default" whereas UAProf uses "Default").
| Element Name | Default Value | Description |
|---|---|---|
| vocabularyFile | uaprofspec.xml | The file containing the vocabulary specification. |
| ccppUri | http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430# | The namespace used for CC/PP constructs such as component. |
| rdfUri | http://www.w3.org/1999/02/22-rdf-syntax-ns# | The namespace used for RDF constructs. |
| componentProperty | component | The name for components. |
| defaultProperty | Default | The name for defaults |
It is easy to configure DELI to recognise legacy
devices via user-agent strings. The legacy device configuration file maps user-agent
strings on to profile references on a profile repository.
By default this is done in the legacyDevice.xml file, although it is
possible to select a different file.
The legacy device configuration file has the following format:
Where useragentstring is a device unique string found in
the user-agent string of the device and profileref is a URL
for the appropriate profile on a profile repository.
Once you have got DELI running on Cocoon, the next
step in creating a CC/PP aware site is to create some stylesheets that
use profile information. DELI makes CC/PP or UAProf attributes available
to XSLT stylesheets as parameters. As CC/PP attributes are unique
within a profile, the component information is omitted. Hence to retrieve the
CcppAccept attribute you use the XPath deli-capabilities/browser/CcppAccept
whereas to retrieve the ScreenSize attribute you use the
XPath deli-capabilities/browser/ScreenSize.
In addition where attributes contain multiple values e.g. Bags or Sequences
those values are separated using ]]> elements.
Hence to retrieve the individual elements you use the XPath
deli-capabilities/browser/CcppAccept/li.
The following code demonstrates how to retrieve both a simple and a complex
attribute: