|
|
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 protocol for transmitting CC/PP profiles has been
proposed but is based on an experimental
variant of HTTP known as HTTP-ex so is not compatible with existing servers.
Therefore DELI uses the W-HTTP protocol proposed by UAProf. This has identical functionality to the CC/PP
protocol based on HTTP-ex, but is compatible with HTTP/1.1.
|
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 the W-HTTP protocol.
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:
 |  |  |
 |
<?xml version="1.0"?>
<vocabspec>
<attribute>
<name>CcppAccept</name>
<component>SoftwarePlatform</component>
<collectionType>Bag</collectionType>
<attributeType>Literal</attributeType>
<resolution>Append</resolution>
</attribute>
</vocabspec>
|  |
 |  |  |
DELI can also read vocabularies described using RDF schemas. The WAP Forum have
published two such schemas to describe the two versions of UAProf currently in use. However
RDF Schema does not provide an easy way of describing attributeType or resolution rule.
Therefore the UAProf schemas store this information in the comments field for each attribute.
Therefore DELI also parses the comments fields to create the vocabulary. This is not an ideal
solution so hopefully a more robust way of representing this information will be used in later versions of UAProf.
|
An
example W-HTTP request using this protocol is shown below:
 |  |  |
 |
GET /ccpp/html/ HTTP/1.1
Host: localhost
x-wap-profile:"http://127.0.0.1:8080/ccpp/profiles/test09defaults.rdf",
"1-Rb0sq/nuUFQU75vAjKyiHw=="
x-wap-profile-diff:1;<?xml version="1.0"?>
<rdf: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:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">
<rdf:Description rdf:ID="MyDeviceProfile">
<prf:component>
<rdf:Description rdf:ID="HardwarePlatform">
<rdf:type
rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-
20010426#HardwarePlatform"/>
<prf:BitsPerPixel>16</prf:BitsPerPixel>
</rdf:Description>
</prf:component>
</rdf:Description>
</rdf:RDF>
|  |
 |  |  |
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
 |  |  |
 |
http://127.0.0.1:8080/ccpp/profiles/test09defaults.rdf.
|  |
 |  |  |
After the profile reference, there is a value
 |  |  |
 |
1-Rb0sq/nuUFQU75vAjKyiHw==
|  |
 |  |  |
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.
|
 |  |  |
 | Writing CC/PP and UAProf aware stylesheets |  |
 |  |  |
For more information on the DELI library please refer to the
DELI web-site.
|
|
|