Abstract
This document describes CC/PP (Composite Capabilities/Preference Profiles)
structure and vocabularies. A CC/PP profile is a description of device capabilities
and user preferences that can be used to guide the adaptation of content presented
to that device.
The Resource Description Framework (RDF) is used to create profiles that describe
user agent and proxy capabilities and preferences. The structure of a profile
is discussed. Topics include:
- structure of client capability and preference descriptions,
- structure of proxy behavior description, as this modifies the set of capabilities
and preferences to which an origin server may respond, AND
- use of RDF classes to distinguish different elements of a profile, so that
a schema-aware RDF processor can handle CC/PP profiles embedded in other xml
document types.
CC/PP vocabulary is identifiers (URIs) used to refer to specific capabilities
and preferences, and covers:
Status of this document
This section describes the status of this document at the time of its
publication. Other documents may supersede this document. The
latest
status of this series of documents is maintained at the W3C.
This is a W3C Last Call Working Draft. Last call means that the working
group believes that this specification is ready and therefore wishes this
to be the last call for comments. If the feedback is positive, the working
group plans to submit it for consideration as a W3C Proposed
Recommendation. Comments can be sent until the 5th of April, 2001. The
decision to issue this last call was made at the working group's meeting
on November 14 , see the
minutes and
at the teleconference on January 11, see the
minutes(Member-only link).
The working group is part of the W3CDevice Independence
activity.
Continued status of the work is reported on
the CC/PP Working Group Home Page
(Member-only link).
This document incorporates suggestions resulting from reviews and
active participation by members of the IETF CONNEG working group and
the WAP Forum UAprof drafting committee, and also significant
restructuring decided at the CC/PP working group
meeting in Karlstad during November 2000. As a result,
this document is created from merge of
CC/PP Structure and
CC/PP Vocabularies.
Please send comments and feedback to www-mobile@w3.org,
the public forum for discussion of W3C's work on Mobile Web Access.
A list of current W3C Recommendations and other technical documents
can be found at http://www.w3.org/TR/.
Table of contents
1. Introduction
A CC/PP profile is a description of device capabilities and user preferences
that can be used to guide the adaptation of content presented to that device.
As the number and variety of devices connected to the Internet grows, there
is a corresponding increase in the need to deliver content that is tailored
to the capabilities of different devices. Some limited techniques, such as HTTP
'accept' headers and HTML <alt> tags, already
exist. As part of a framework for content adaptation and contextualization,
a general purpose profile format is required that can describe the capabilities
of a user agent and preferences of its user. CC/PP is designed to be such a
format.
CC/PP is based on RDF, the Resource Description Framework, which was designed
by the W3C as a general purpose metadata description language. RDF provides
the framework with the basic tools for both vocabulary extensibility, via XML
namespaces, and interoperability. There is a specification that describes how
to encode RDF using XML [3], and another that defines
an RDF schema description language using RDF [4]. RDF
was designed to describe the metadata or machine understandable properties of
the Web. RDF is a natural choice for the CC/PP framework since user agent profiles
are metadata intended primarily for communication between user agents and resource
data providers.
A CC/PP profile contains a number of 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 and/or proxy to describe
their 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.
Some information contained in a profile may be sensitive, and adequate trust
and security mechanisms must be deployed to protect users' privacy. As a part
of a wider application, CC/PP cannot fully cover such issues, but is intended
to be used in conjunction with appropriate mechanisms. This topic is covered
in the Appendix F, CC/PP applications.
It is anticipated that different applications will use different vocabularies;
indeed this is needed if application-specific properties are to be represented
within the CC/PP framework. But for different applications to work together,
some common vocabulary, or a method to convert between different vocabularies,
is needed. (XML namespaces can ensure that different applications' names do
not clash, but does not provide a common basis for exchanging information between
different applications.) Any vocabulary that relates to the structure of a CC/PP
profile must follow this specification. The appendices introduce some simple
attribute vocabulary that may be used to improve cross-application exchange
of capability information, partly based on some earlier IETF work.
CC/PP is designed to be broadly compatible with the earlier UAPROF specification
[9] from the WAP Forum. That is, any valid UAPROF profile
is intended to be a valid CC/PP profile.
1.1 Scope and normative elements
CC/PP is a client profile data format, and a framework for incorporating application-
and operating environment-specific features. It does not define how the profile
is transferred, nor does it specify what CC/PP attributes must be generated
or recognized. CC/PP is designed for use as part of a wider application framework.
As such, the specification of CC/PP elements that must be supported and those
which may be omitted is a matter for a specific application.
There are few protocol assumptions built into the design of CC/PP. Although
it is intended to be largely protocol independent, particular consideration
has been given to use of CC/PP with HTTP for retrieving web resources. Appendix
F contains some further discussion of CC/PP applications.
This document describes a number of features of CC/PP. Some features form
part of the essential structure of CC/PP, for which conformance is REQUIRED.
Others are features whose use is RECOMMENDED or OPTIONAL. There is also discussion
of how new vocabularies should be introduced, directed to CC/PP application
designers rather than implementers.
The architecture section does not describe specific features, but indicates
general principles that underlie the design of CC/PP. As such, it is not specifically
normative but does contain information that should be understood for proper
implementation of CC/PP.
The section on CC/PP structure covers three main areas:
- CC/PP profile components: support for these is REQUIRED.
- CC/PP profile defaults: support for these is REQUIRED.
- CC/PP proxy behavior descriptions: support for these is RECOMMENDED for
applications which make use of proxies or other intermediaries that may extend
or vary the range of capabilities that may be assumed by an information provider.
The section on CC/PP attribute vocabularies describes some general features
of CC/PP attributes and their values. Support for the described formats for
simple attribute values is RECOMMENDED -- the actual syntax for any simple CC/PP
value is defined by the corresponding attribute specification; such specifications
may reference the information provided here. Support for the structured CC/PP
attribute formats described, where relevant, is REQUIRED.
Support is not required for any specific vocabulary, but application designers
are strongly encouraged to re-use existing vocabularies where possible.
CC/PP applications are not required to support features described in the appendices,
but any new attribute vocabularies defined MUST conform to the RDF schema in
appendices B and C.
1.2 Structure of this document
The remainder of this section covers terminology, conventions and notations
used in this document.
Section 2 provides an overview of the CC/PP profile structure, use of XML namespaces,
RDF data model and RDF Schemas.
Section 3 describes the structure of a CC/PP profile, and introduces the RDF
elements that are used to create the essential CC/PP elements.
Section 4 describes how attributes are used in a CC/PP profile, and presents
the recommended structure of CC/PP elements used to describe specific features.
The appendices contain additional supporting material that is not essential
to construct a valid CC/PP profile, but which provides additional background
information useful for understanding CC/PP, its relationship with RDF, or defining
attribute vocabularies for specific applications.
1.3 Document conventions
1.3.1 Terminology
See CC/PP terminology and abbreviations in Appendix
A of this document.
The term "CC/PP attribute" is used here to refer to a
specific capability or characteristic of a client (or other system) that appears
in a CC/PP profile. The term "feature" refers to a client
capability or characteristic that may or may not be the basis of a CC/PP attribute.
The term "attribute name" is used to indicate an RDF property
name used to identify a CC/PP attribute.
In describing the construction of profiles that incorporate proxy behaviors,
the terms "inbound" and "outbound"
are used in the sense described in the HTTP/1.1 specification, RFC 2616 [31].
That is: "inbound" means "toward the origin server", and "outbound" means "toward
the user agent".
The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," "MAY," and "MAY NOT"
in this document are to be interpreted as described in RFC 2119 [25].
1.3.2 RDF graph notation
The underlying structure of RDF is a directed labelled graph. For communication
between computer systems, RDF uses a serialization in XML to represent these
graphs. This XML notation is rather bulky and difficult for human discourse,
so a more visual notation is used here for describing RDF graph structures:
-
Figure 1-1: RDF graph notation
[Subject-resource] --propertyName--> [Object-resource]
Indicates a graph edge labelled 'propertyName' from an RDF
resource named 'Subject-resource' to another RDF resource names 'Object-resource'.
[Subject-resource] --propertyName--> "Property value"
Indicates a graph edge labelled 'propertyName' from an RDF
resource named 'Subject-resource' to a literal string containing the
indicated value.
[Subject-resource] --propertyName--> { "Val1", "Val2", ... }
This is a shorthand for a property whose value is an rdf:Bag
resource containing the indicated values (see section 4.1.2.1).
[<Subject-type>] --propertyName--> [<Object-type>]
Names in angle brackets are used to indicate an RDF resource
of the indicated type (i.e. having the indicated rdf:Type property
value), without indicating a specific name for the resource. This is
useful for showing the RDF classes that may be linked by a property.
[Subject-resource] --propertyName--> [Object-resource]
|
-------------------------------
|
+--property1--> (val1)
+--property2--> (val2)
:
(etc.)
Property arcs can be chained, and multiple arcs drawn from
a subject resource.
|
Here are some XML examples of the RDF graph structures described
above:
Figure 1-2: RDF graph example in XML
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<!-- Any RDF graph is an RDF element
-->
<RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns="http://www.example.com/schema#">
<!-- [Subject-resource] -propertyName-> [Object-resource]
-->
<rdf:Description rdf:about="Subject-resource">
<propertyName>
<rdf:Description rdf:about="Object-resource" />
</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> [Object-resource]
- (Alternative format)
-->
<rdf:Description rdf:about="Subject-resource">
<propertyName rdf:resource="Object-resource" />
</rdf:Description>
<!-- [Subject-resource] -propertyName-> "property value"
-->
<rdf:Description rdf:about="Subject-resource">
<propertyName>Property value</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... }
-->
<rdf:Description rdf:about="Subject-resource">
<propertyName>
<rdf:Description>
<rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
<rdf:li>Val1</rdf:li>
<rdf:li>Val1</rdf:li>
<!-- ...etc... -->
</rdf:Description>
</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... }
- (Alternative format)
-->
<rdf:Description rdf:about="Subject-resource">
<propertyName>
<rdf:Bag>
<rdf:li>Val1</rdf:li>
<rdf:li>Val1</rdf:li>
<!-- ...etc... -->
</rdf:Bag>
</propertyName>
</rdf:Description>
<!-- [<Subject-type>] -propertyName-> [<Object-type>]
-->
<rdf:Description>
<rdf:type rdf:resource="Subject-type" />
<propertyName>
<rdf:Description>
<rdf:type rdf:resource="Object-type" />
</rdf:Description>
</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> [Object-resource]
- |
- +-property1-> (val1)
- +-property2-> (val2)
- :
-->
<rdf:Description rdf:about="Subject-resource">
<propertyName>
<rdf:Description rdf:about="Object-resource" >
<property1>val1</property1>
<property2>val2</property2>
<!-- ...etc... -->
</rdf:Description>
</propertyName>
</rdf:Description>
</RDF>
|
2. CC/PP architecture
2.1 CC/PP profile structure
A CC/PP profile is broadly constructed as a 2-level hierarchy:
- a profile having a number of components, and
- each component having a number of attributes.
The initial branches of the CC/PP profile tree describe major components of
the client. Examples of major components are:
- the hardware platform upon which software is executing,
- the software platform upon which all applications are hosted, or
- an individual application, such as a browser.
A simple, graphical representation of the bottom of a CC/PP tree based on three
components (TerminalHardware, TerminalSoftware and
TerminalBrowser) would be:
Figure 2-1a: CC/PP profile components
[Profile]
|
+--ccpp:component-->[TerminalHardware]
+--ccpp:component-->[TerminalSoftware]
+--ccpp:component-->[TerminalBrowser]
|
The corresponding XML might look like this:
Figure 2-1b: CC/PP profile components in
XML
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="Profile">
<ccpp:component>
<rdf:Description rdf:about="TerminalHardware">
<!-- TerminalHardware properties here -->
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="TerminalSoftware">
<!-- TerminalSoftware properties here -->
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description about="TerminalBrowser">
<!-- TerminalBrowser properties here -->
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
|
A CC/PP profile describes client capabilities and preferences in terms of a
number of "CC/PP attributes" for each component.
The description of each component is a sub-tree whose branches are the capabilities
or preferences associated with that component. Though RDF makes modeling a wide
range of data structures possible, including arbitrary graphs, complex data
models are usually best avoided for profile attribute values. A capability can
often be described using a small number of CC/PP attributes, each having a simple,
atomic value. Where more complex values are needed, these can be constructed
as RDF subgraphs. One useful useful case for complex attribute values is to
represent alternative values; e.g. a browser may support multiple versions of
HTML. A hypothetical profile might look like this:
Figure 2-2a: Complete CC/PP profile
example
[MyProfile]
|
+--ccpp:component-->[TerminalHardware]
| |
| +--rdf:type---> [HardwarePlatform]
| +--display----> "320x200"
|
+--ccpp:component-->[TerminalSoftware]
| |
| +--rdf:type---> [SoftwarePlatform]
| +--name-------> "EPOC"
| +--version----> "2.0"
| +--vendor-----> "Symbian"
|
+--ccpp:component-->[TerminalBrowser]
|
+--rdf:type---> [BrowserUA]
+--name-------> "Mozilla"
+--version----> "5.0"
+--vendor-----> "Symbian"
+--htmlVersionsSupported--> [ ]
|
-------------------------
|
+--rdf:type---> [rdf:Bag]
+--rdf:_1-----> "3.0"
+--rdf:_2-----> "4.0"
|
The corresponding XML might look like this:
Figure 2-2b: Complete CC/PP profile example in
XML
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="MyProfile">
<ccpp:component>
<rdf:Description rdf:about="TerminalHardware">
<rdf:type rdf:resource="HardwarePlatform" />
<display>320x200</display>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="TerminalSoftware">
<rdf:type rdf:resource="SoftwarePlatform" />
<name>EPOC</name>
<version>2.0</version>
<vendor>Symbian</vendor>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="TerminalBrowser">
<rdf:type rdf:resource="BrowserUA" />
<name>Mozilla</name>
<version>5.0</version>
<vendor>Symbian</vendor>
<htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</htmlVersionsSupported>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
|
The attributes of a component can be included directly, as in the previous
example, or may be specified by reference to a default profile, which may be
stored separately and accessed using its specified URI.
This use of an externally defined default properties is somewhat similar to
the idea of dynamic inheritance. It makes possible some important optimizations.
As a separate document, it can reside at a separate location and it can be separately
cached. This is particularly useful in wireless environments such as cellular
networks, where the profiles may be large and the client link slow and expensive.
Using default values, only a small part of the overall profile is sent over
the wireless network.
Figure 2-3a: CC/PP profile using defaults
[MyProfile]
|
+--ccpp:component--> [TerminalHardware]
| |
| +--rdf:type-------> [HardwarePlatform]
| +--ccpp:defaults--> [HWDefault]
|
+--ccpp:component--> [TerminalSoftware]
| |
| +--rdf:type-------> [SoftwarePlatform]
| +--ccpp:defaults--> [SWDefault]
|
+--ccpp:component--> [TerminalBrowser]
|
+--rdf:type-------> [BrowserUA]
+--ccpp:defaults--> [UADefault]
[HWDefault]
|
+--rdf:type---> [HardwarePlatform]
+--display----> "320x200"
[SWDefault]
|
+--rdf:type---> [SoftwarePlatform]
+--name-------> "EPOC"
+--version----> "2.0"
+--vendor-----> "Symbian"
[UADefault]
|
+--rdf:type---> [BrowserUA]
+--name-------> "Mozilla"
+--version----> "5.0"
+--vendor-----> "Symbian"
+--htmlVersionsSupported--> [ ]
|
+--rdf:type---> [rdf:Bag]
+--rdf:_1-----> "3.0"
+--rdf:_2-----> "4.0"
|
The corresponding XML might look like this:
Figure 2-3b: CC/PP profile using defaults in
XML
Device profile referencing defaults:
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="MyProfile">
<ccpp:component>
<rdf:Description rdf:about="TerminalHardware">
<rdf:type rdf:resource="HardwarePlatform" />
<ccpp:defaults rdf:resource="HWDefault" />
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="TerminalSoftware">
<rdf:type rdf:resource="SoftwarePlatform" />
<ccpp:defaults rdf:resource="SWDefault" />
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="TerminalBrowser">
<rdf:type rdf:resource="BrowserUA" />
<ccpp:defaults rdf:resource="UADefault" />
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
Defaults for HardwarePlatform:
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="HWDefault">
<rdf:type rdf:resource="HardwarePlatform" />
<display>320x200</display>
</rdf:Description>
</rdf:RDF>
Defaults for SoftwarePlatform:
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="SWDefault">
<rdf:type rdf:resource="SoftwarePlatform" />
<name>EPOC</name>
<version>2.0</version>
<vendor>Symbian</vendor>
</rdf:Description>
</rdf:RDF>
Defaults for BrowserUA:
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="UADefault">
<rdf:type rdf:resource="BrowserUA" />
<name>Mozilla</name>
<version>5.0</version>
<vendor>Symbian</vendor>
<htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</htmlVersionsSupported>
</rdf:Description>
</rdf:RDF>
|
If a given attribute value is applied directly to a component resource, and
also appears on a resource referenced by the ccpp:defaults
property, the directly applied value takes precedence:
Figure 2-4a: Overriding a default
value
[MyProfile]
|
+--ccpp:component--> [TerminalHardware]
|
+--rdf:type-------> [HardwarePlatform]
+--ccpp:defaults--> [HWDefault]
+--memory---------> "32Mb"
[HWDefault]
|
+--rdf:type---> [HardwarePlatform]
+--display----> "320x200"
+--memory-----> "16Mb"
|
In this example, the default component indicates 16Mb of memory, but this value
is overridden by the memory property applied directly to the profile
component. Thus, in this profile, the memory attribute has a value
of 32Mb.
The corresponding XML might look like this:
Figure 2-4b: Overriding a default value in
XML
Device profile referencing defaults:
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="MyProfile">
<ccpp:component>
<rdf:Description rdf:about="TerminalHardware">
<rdf:type rdf:resource="HardwarePlatform" />
<ccpp:defaults rdf:resource="HWDefault" />
<memory>32Mb</memory>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
Defaults for HardwarePlatform:
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#">
<rdf:Description rdf:about="HWDefault">
<rdf:type rdf:resource="HardwarePlatform" />
<display>320x200</display>
<memory>16Mb</memory>
</rdf:Description>
</rdf:RDF>
|
A resource indicated by a default property may appear in a separate document,
in which case an absolute URI reference should be specified for the default
resource. In such cases, the URI part of the default resource identifier (i.e.
not including the fragment identifier part) is used to retrieve an RDF document
containing the default resource description. Thus, if the default resource is
named http://example.com/DeviceProfile#HardwarePlatform, the URI
http://example.com/DeviceProfile is used to retrieve an RDF document,
and a resource within that document having the local identifier #HardwarePlatform
is taken as the default resource. (Such a resource might be defined within the
target document using "about='http://example.com/DeviceProfile#HardwarePlatform'"
or "ID='HardwarePlatform'". See also section 3.1.5.)
NOTE: individual applications may allow relative URIs to be
used. Those that do should specify exactly how the corresponding RDF document
is located.
It may be that an intervening network element, such as a transcoding proxy,
has additional capabilities it wishes to advertise on the behalf of its clients.
For instance, a transcoding proxy may be able to convert HTML to WML. The means
to provision such a proxy (meaning to provide or not provide the service for
some client) is beyond the scope of this work. But assuming such a proxy based
capability is provided, CC/PP provides means for a proxy to describe its own
capabilities as part of the CC/PP profile communicated to an origin server.
In the example below, the proxy profile showing its capabilities combined with
a client profile by a request profile link element. This is not a particularly
representative example, but it does illustrate how a proxy profile can contain
different kinds of component information:
Figure 2-5: Proxy profile combined with client profile
in request profile
Client Profile:
[ClientProfile]
|
+--ccpp:component-->[TerminalHardware]
| |
| +--rdf:type---> [HardwarePlatform]
| +--display----> "320x200"
|
+--ccpp:component-->[TerminalSoftware]
| |
| +--rdf:type---> [SoftwarePlatform]
| +--name-------> "EPOC"
| +--version----> "2.0"
| +--vendor-----> "Symbian"
|
+--ccpp:component-->[TerminalBrowser]
|
+--rdf:type---> [BrowserUA]
+--name-------> "Mozilla"
+--version----> "5.0"
+--vendor-----> "Symbian"
+--htmlVersionsSupported--> { "3.0","4.0" }
Proxy Profile:
[ProxyProfile]
|
+--proxyBehavior--> [ ]
| |
| +--proxyAllow--> [ProxyHardware]
| |
| +--rdf:type--> [HardwarePlatform]
| +--cpu-------> "Pentium III"
|
+--proxyBehavior--> [ ]
| |
| +--proxyAllow--> [ProxyOS]
| |
| +--rdf:type--> [SoftwarePlatform]
| +--name------> "Linux"
| +--vendor----> "Linux.com"
| +--version---> "5.0"
|
+--proxyBehavior--> [ ]
|
+--proxyAllow--> [Proxy]
|
+--rdf:type--> [ProxyComponent]
+--name------> ""
+--vendor----> "Interleaf"
+--version---> "1.0"
+--html4.0towml1.1--> "Yes"
Request Profile:
[RequestProfile]
|
+--nextProfile---> [ClientProfile]
+--proxyProfile--> [ProxyProfile]
|
Examples of proxy behavior descriptions in XML can be found in section 3.2.
There may be multiple intervening network hosts, each of which, needs to be
able to indicate some capability. In general, the order in which these network
hosts are encountered is important. For example, consider an installation with
a firewall that filters some types of unsafe content and a transcoding proxy
that converts the unsafe content to a safe form. If the proxy is behind the
firewall then the origin server cannot send the unsafe form for the transcoding
proxy to convert, because the firewall will block it first. But it is a different
story if the proxy is in front of the firewall.
To indicate sequence of proxies on a path, multiple request profiles (each
referencing a proxy profile) can be chained together. Proxies that are closer
to the origin server appear earlier in the chain, with the client profile being
last in the chain:
Figure 2-6: Request profile chain, ending with client
profile
[<Request-profile-n>]
+--proxyProfile--> [<Proxy-profile-n>]
+--nextProfile---> [<Request-profile-(n-1)>]
|
-----------------
|
v
[<Request-profile-(n-1)>]
:
:
v
[<Request-profile-2>]
+--proxyProfile--> [<Proxy-profile-2>]
+--nextProfile---> [<Request-profile-1>]
|
-----------------
|
v
[<Request-profile-1>]
+--proxyProfile--> [<Proxy-profile-1>]
+--nextProfile---> [<Client-profile>]
+--component--> [...]
|
An XML version of this is presented in section 3.2.1.
2.2 Extensibility and namespaces
CC/PP is extended primarily through the introduction of new attribute vocabularies.
Any application or operational environment that uses CC/PP may define its own
vocabulary, but wider interoperability is enhanced if vocabularies are defined
that can be used more generally; e.g. a standard extension vocabulary for imaging
devices, or voice messaging devices, or wireless access devices, etc. Accordingly,
this specification defines a small core vocabulary of features that are applicable
to range of print and display agents whose use, where appropriate, is strongly
recommended. This core vocabulary is based on IETF specification RFC2534 [8],
and serves as an example of how CC/PP attribute vocabularies may be defined.
Another such example is the WAP Forum UAPROF specification [9].
Any CC/PP expression can use terms drawn from an arbitrary number of different
vocabularies, so there is no restriction caused by re-using terms from an existing
vocabulary rather then defining new names to identify the same information.
Each vocabulary is associated with an XML namespace, as are the names that describe
the underlying RDF and CC/PP structures.
XML namespaces [2] define a notation for associating
convenient name forms with arbitrary URIs. The RDF graph syntax does not specifically
employ namespaces, but XML serializations of an RDF graph do. We also use namespace
prefixes when presenting RDF in the graph notation described above.
There is a reasonable expectation that a designated (globally unique) namespace
will have associated semantics, including schema-related semantics. Thus, there
is a convention that a namespace URI is associated with a corresponding schema
document, though the specific mechanism for determining such an association
is not formally defined. (The RDF schema specification does say that the namespace
identifier is also used as a schema identifier.)
The CC/PP framework uses the XML namespace mechanism to create identifying
URIs for RDF core elements, CC/PP structural elements and CC/PP attribute vocabularies.
Consider the following namespace declaration example:
Figure 2-7: Example namespace
declarations
<?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-20000405#">
|
The first two namespace declarations are for RDF usage. The third declaration
names the CC/PP core structural vocabulary, which includes "component",
"defaults" and other properties that are intrinsic to the CC/PP
framework. The fourth namespace declaration names a component properties vocabulary.
The use of multiple component property vocabularies is allowed and encouraged.
Different user communities and application domains (WAP Forum, ETSI, MExE, IETF
CONNEG, etc.) may define their own property vocabularies. This is an important
mechanism for providing support for the needs of those communities.
The following namespaces are introduced by the CC/PP framework:
http://www.w3.org/2000/07/04-ccpp#
RDF class declarations for CC/PP, and core structural properties.
http://www.w3.org/2000/07/04-ccpp-proxy#
Vocabulary for describing proxy behaviors in a CC/PP profile.
http://www.w3.org/2000/07/04-ccpp-client#
Vocabulary for describing simple client capabilities, with particular
relevance to print and display clients.
2.3 RDF background
RDF is defined in the RDF Model and Syntax specification [3].
The foundation of RDF is a directed labelled graph used to represent entities,
concepts and relationships between them. This RDF model draws on principles
of knowledge representation developed over the past decades in the artificial
intelligence community, notably conceptual graphs [32].
A broader background to knowledge representation issues can be found in Sowa's
book Knowledge Representation [33]. RDF
extends the traditional approach to knowledge representation by placing it in
the open context of the World Wide Web, in which anybody may make any statement
about anything.
The nodes of an RDF graph are resources, which may
stand for entities or concepts. Commonly, these nodes stand for web resources,
but RDF itself does not impose any such constraint on the nature of a resource.
The arcs of an RDF graph are properties. Commonly,
these are used to denote attributes of a resource, but may also be used to indicate
any relationship between any pair of resources.
The fundamental construct of RDF is a statement, which corresponds
to a labelled directed arc between two nodes of the graph. A statement thus
consists of three components: an originating resource known as the subject
of the statement, a target resource (or literal) known as the object,
and a property known as the predicate:
-
Figure 2-8: Parts of an RDF
statement
RDF subject RDF predicate RDF object
[Resource] ----attributeName----> (Attribute-value)
URI prefix:name URI
or
URI#fragment-ID
or
literal
|
Thus, the basic RDF data model consists of three object types:
- Resources
- All things being described by RDF expressions are called resources. A resource
may be an entire Web page; the HTML document
http://www.w3.org/Overview.html,
for example. A resource may be a part of a Web page; e.g. a specific HTML
or XML element within the document source. A resource may also be a whole
collection of pages; e.g. an entire Web site. A resource may also be an object
that is not directly accessible via the Web; e.g. a printed book. Resources
are always named by URIs plus optional anchor ids (see RFC2396 [28]).
Anything can have a URI; the extensibility of URIs allows the introduction
of identifiers for any entity imaginable.
- Properties
- A property is a specific aspect, characteristic, attribute, or relation
used to describe a resource. Each property has a specific meaning, defines
its permitted values, the types of resources it can describe, and its relationship
with other properties. This document does not address how the characteristics
of properties are expressed; for such information, refer to the RDF Schema
specification [4].
- Statements
- A specific resource together with a named property plus the value of that
property for that resource is an RDF statement. These three individual parts
of a statement are called, respectively, the subject, the predicate, and the
object. The object of a statement (i.e., the property value) can be another
resource or it can be a literal; i.e., a resource (specified by a URI) or
a simple string or other primitive datatype defined by XML. In RDF terms,
a literal may have content that is XML markup but is not further evaluated
by the RDF processor. There are some syntactic restrictions on how markup
in literals may be expressed; see Section 6.2.1.
An RDF graph is expressed in XML using syntax described in the RDF Model
and Syntax specification [3].
An RDF subject resource and a number of associated properties is contained
in an <rdf:Description> element, with an rdf:ID=
or rdf:about= attribute identifying the subject resource.
Each property is expressed as a child element of the <rdf:Description>
element whose content is either another resource description or the literal
value of the property, or as an empty property element with an rdf:resource=
attribute identifying a resource that is described elsewhere:
Figure 2-9a: XML fragment containing RDF
resource description
<Description rdf:about="http://example.com/MyProfile">
<ccpp:component>
<Description rdf:about="http://example.com/Schema#TerminalHardware">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
<prf:cpu>PPC</prf:cpu>
<prf:display>320x200</prf:display>
</Description>
</ccpp:component>
</Description>
|
The RDF graph described by this is:
Figure 2-9b: Graph of RDF resource
description
[http://example.com/MyProfile]
|
+--ccpp:component-->[http://example.com/Schema#TerminalHardware]
|
-----------------
|
+--rdf:type-------> [http://example.com/Schema#HardwarePlatform]
+--prf:cpu--------> "PPC"
+--prf:display----> "320x200"
|
A complete RDF serialization consists of an <rdf:RDF>
element containing a sequence of such descriptions (and appropriate namespace
declarations):
Figure 2-10: RDF serialization
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://example.com/schema#">
<Description about="http://example.com/MyProfile">
<ccpp:component>
<Description
about="http://example.com/schema#TerminalHardware">
<type resource="http://example.com/Schema#HardwarePlatform" />
<prf:cpu>PPC</prf:cpu>
<prf:display>320x200</prf:display>
</Description>
</ccpp:component>
<!-- ...etc... -->
</Description>
</RDF>
|
This is the so-called "basic RDF serialization syntax. RDF also defines
some abbreviated forms that can be used, as appropriate, to make the XML data
more compact, and in some cases easier to read:
- use of an
rdf:type property value as element name for
a resource description,
- use of
<rdf:Description> element attributes to
represent literal property values, and
- use of an
rdf:resource= attribute of a property element
to indicate a resource value, together with additional attributes to indicate
literal properties of the indicated resource.
The first of these abbreviation forms is often used to construct RDF serialization
that looks similar to commonly used XML forms. using this, the inner description
of the above example would become:
Figure 2-11: RDF 'type' abbreviation
syntax
<prf:HardwarePlatform
rdf:about="http://example.com/schema#TerminalHardware">
<prf:cpu>PPC</prf:cpu>
<prf:display>320x200</prf:display>
</prf:HardwarePlatform>
|
Note that when used as an attribute value, a resource identifier URI must be
written out in full. When used as an element name or attribute name, a namespace
prefix form must be used to conform to XML syntax. (This is one of the oddities
of the XML serialization syntax of RDF.)
RDF properties may be thought of as attributes of resources and in this sense
used to represent traditional attribute-value pairs. RDF properties also represent
relationships between resources. As such, the RDF data model can therefore resemble
an entity-relationship diagram. The RDF data model, however, provides no mechanisms
for declaring these properties, nor does it provide any mechanisms for defining
the relationships between these properties and other resources. That is the
role of RDF Schema.
RDF schema introduces the key concept of a "class". This
provides the basis for categorizing RDF resources and properties, and provides
the fundamental mechanism for constructing RDF ontologies. (Ontology applies
the idea of a data type to a wide range of entities and concepts; it thus provides
a basis for organizing and categorizing resources about which statements are
made.)
An RDF schema can declare constraints associated with classes and properties.
In particular, the concepts of domain and range are used to make statements
about the kinds of resource that can be related by a given property. Although
the RDF data model does not allow for explicit properties (such as an rdf:type
property) to be ascribed to Literals (atomic string values), we nevertheless
consider these entities to be members of classes (e.g. the string "John Smith"
is considered to be a member of the class rdfs:Literal).
Specifc constraint types that may be defined by an RDF schema are rdfs:domain
and rdfs:range. For example, consider that a resource of
type 'Book' may have a property 'author' whose value
is a 'Person':
rdfs:domain expresses that a property can be applied
only to instances of a designated class; e.g. that the subject of any 'author'
property must be an instance of class 'Book'.rdfs:range expresses that an indicated property must
have a value that is an instance of a designated class; e.g. that the object
of any 'author' property must be an instance of class 'Person'.
RDF schemas can express constraints that relate vocabulary items from multiple
independently developed schemas. Since URI references are used to identify classes
and properties, it is possible to create new properties whose domain or range
is constrained to be a class defined in another namespace.
The RDF Schema uses the constraint properties to constrain how its own properties
can be used. These constraints are shown below in figure 7. Nodes with bold
outlines are instances of rdfs:Class.
Please refer to the RDF Schema [4] for a more complete
description of RDF Constraints.
3. CC/PP structure
3.1 Client profile
The general structure of a CC/PP client profile is a two-level tree: components
and attributes, with provision for each component to reference an externally
defined set of default attribute values.
3.1.1 Components
A CC/PP profile contains a number of components. Each component
is represented by a resource of type ccpp:Component
(or some subclass thereof), and related to the client profile resource by a
ccpp:component property.
A CC/PP profile based on three components (TerminalHardware, TerminalSoftware
and TerminalBrowser), would look like this:
Figure 3-1: CC/PP profile components
example
[Profile]
|
+--ccpp:component-->[TerminalHardware]
+--ccpp:component-->[TerminalSoftware]
+--ccpp:component-->[TerminalBrowser]
|
A ccpp:Component resource MAY have an rdf:type
property (or equivalent RDF structure) indicating what kind of client component
it describes. The example in figures 3-4 is of a profile with an explicit indication
of component subtype. However, CC/PP processors MUST be able to handle profiles
that do not contain component type indicators. As long as the CC/PP attributes
used are all specific to a given component type, a processor will have sufficient
information to interpret them properly.
If a CC/PP profile uses any attribute that can appear on different component
types, then the type of any component on which such an attribute appears MUST
be indicated by an rdf:type property, or equivalent RDF.
A CC/PP processor MUST be able to use this type information to disambiguate
application of any attribute used.
3.1.2 Attributes
CC/PP profiles are constructed using RDF [3]. The RDF data
model represents CC/PP attributes as named properties linking a subject
resource to an associated object resource or literal value.
To describe client capabilities and preferences, the client being described
is a resource whose features are described by labelled graph edges from that
resource to corresponding object values. The graph edge labels identify the
client feature (CC/PP attribute) being described, and the corresponding object
values are the feature values.
-
Figure 3-2: RDF statement describing a client
attribute
[Client component resource] --attributeName--> (Attribute-value)
|
Graph labels are XML name values (per XML specification [1],
section 2.3), which may include a namespace prefix (i.e. a qualified name,
per XML namespaces [2], section 3). When combined with
the corresponding namespace or default namespace declaration, each label can
be mapped to a URI. Thus, CC/PP attributes are URIs, with XML namespace syntax
used to avoid some of the RDF expressions becoming too
cumbersome.
RDF object values are resources (identified by a URI without fragment identifier),
resource fragments (identified by a URI with fragment identifier) or literal
values (text strings). The literal values correspond to CC/PP attribute values
with basic data types; other values correspond to structured CC/PP attribute
values.
-
Figure 3-3: Parts of an RDF
statement
RDF subject RDF property RDF object
[Client resource] --attributeName---> (Attribute-value)
URI prefix:name URI
or
URI#fragment-ID
or
literal
|
Basic data types are discussed in the section Simple
CC/PP attribute data. Each basic data type may support a range of tests
that can be used in the process of determining the suitability of different
resource variants for presentation by a client; e.g. equality, compatibility,
less-than, greater-than, etc. Further discussion of CC/PP attribute matching
operations is deferred to a separate document [10].
Structured data types are supported through the use of specific RDF properties
that join simple data values into composites. Specific CC/PP semantics for RDF
properties used in this way are discussed in the section Complex
CC/PP attribute data.
3.1.3 Defaults
Each component of a client profile may indicate a separate resource that in
turn indicates a subordinate collection of default attribute values. This collection
of default values can be a separate RDF document that is named via a URI, or
can appear in the same document as the client profile (though, in practice,
there is probably little value in defaults in the same document). If an attribute
in the collection of defaults is also present in the main part of the client
profile, the non-default value takes precedence. The intent is that a hardware
vendor or system supplier may provide default values that are common to a number
of systems in a place easily accessible to an origin server, and then use the
client profile to specify variations from the common profile. The owner of the
product or system operator may be able to add or change options, such as additional
memory, that add new capabilities or change the values of some original capabilities.
Default values are referenced by the property ccpp:defaults.
This name conforms to the name format recommendations of the RDF model and syntax
specification [3], appendix C.1. However, for compatibility
with earlier versions of CC/PP used with UAPROF, CC/PP processors SHOULD recognize
the property name ccpp:Defaults (i.e. with capital "D")
as equivalent.
Defaults can be encoded inline or as separate documents referred to via URI.
It is the responsibility of any server interpreting a CC/PP to combine profiles
with any externally referenced Defaults in such a way as to be able to correctly
interpret the profile. A profile with defaults in the same document is logically
equivalent to a profile with the same non-default data and referenced external
document(s) containing the default values. Here is a simple profile graph using
default values:
Figure 3-4a: CC/PP profile using
defaults
[MyProfile]
|
+--ccpp:component--> [TerminalHardware]
| |
| +--rdf:type-------> [HardwarePlatform]
| +--ccpp:defaults--> [HWDefault]
| +--display--------> "640x400"
|
+--ccpp:component--> [TerminalSoftware]
| |
| +--rdf:type-------> [SoftwarePlatform]
| +--ccpp:defaults--> [SWDefault]
|
+--ccpp:component--> [TerminalBrowser]
|
------------
|
+--rdf:type-------> [BrowserUA]
+--ccpp:defaults--> [UADefault]
+--htmlVersionsSupported--> { "3.0", "4.0", "XHTML" }
[HWDefault]
|
+--rdf:type--> [HardwarePlatform]
+--cpu-------> "PPC"
+--display---> "320x200"
[SWDefault]
|
+--rdf:type--> [SoftwarePlatform]
+--name------> "EPOC"
+--version---> "2.0"
+--vendor----> "Symbian"
[UADefault]
|
+--rdf:type--> [BrowserUA]
+--name------> "Mozilla"
+--version---> "5.0"
+--vendor----> "Symbian"
+--htmlVersionsSupported--> { "3.0", "4.0" }
|
And here is the corresponding XML serialization, with the default resource
descriptions coded inline in the client profile description:
Figure 3-4b: CC/PP profile using inline defaults, in
XML
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
<Description about="http://example.com/MyProfile">
<ccpp:component>
<Description about="http://example.com/TerminalHardware">
<type resource="http://example.com/Schema#HardwarePlatform"/>
<ccpp:defaults>
<Description about="http://example.com/HWDefault">
<type resource="http://example.com/Schema#HardwarePlatform"/>
<prf:cpu>PPC</prf:cpu>
<prf:display>320x200</prf:display>
</Description>
</ccpp:defaults>
<prf:display>640x400</prf:display>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://example.com/TerminalSoftware">
<type resource="http://example.com/Schema#SoftwarePlatform" />
<ccpp:defaults>
<Description about="http://example.com/SWDefault">
<type resource="http://example.com/Schema#SoftwarePlatform"/>
<prf:name>EPOC</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>2.0</prf:version>
</Description>
</ccpp:defaults>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://example.com/Browser">
<type resource="http://example.com/Schema#BrowserUA" />
<ccpp:defaults>
<Description about="http://example.com/UADefault">
<type resource="http://example.com/Schema#BrowserUA"/>
<prf:name>Mozilla</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>5.0</prf:version>
<prf:htmlVersionsSupported>
<Bag>
<li>3.0</li>
<li>4.0</li>
</Bag>
</prf:htmlVersionsSupported>
</Description>
</ccpp:defaults>
<prf:htmlVersionsSupported>
<Bag>
<li>3.0</li>
<li>4.0</li>
<li>XHTML</li>
</Bag>
</prf:htmlVersionsSupported>
</Description>
</ccpp:component>
</Description>
</RDF>
|
Inline defaults are logically equivalent to defaults contained in externally
referenced document, and external documents would be normal way of referencing
default values. The following is the external the XML serialization of the same
profile using externally referenced defaults:
Figure 3-5: CC/PP profile referencing
externally defined defaults, in XML
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
<Description about="http://example.com/MyProfile">
<ccpp:component>
<Description about="http://example.com/TerminalHardware">
<type resource="http://example.com/Schema#HardwarePlatform"/>
<ccpp:defaults rdf:resource="http://example.com/HWDefault"/>
<prf:display>640x400</prf:display>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://example.com/TerminalSoftware">
<type resource="http://example.com/Schema#SoftwarePlatform" />
<ccpp:defaults rdf:resource="http://example.com/SWDefault"/>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://example.com/Browser">
<type resource="http://example.com/Schema#BrowserUA" />
<ccpp:defaults rdf:resource="http://example.com/UADefault"/>
<prf:htmlVersionsSupported>
<Bag>
<li>3.0</li>
<li>4.0</li>
<li>XHTML</li>
</Bag>
</prf:htmlVersionsSupported>
</Description>
</ccpp:component>
</Description>
</RDF>
|
Each external defaults resource is a separate RDF document referenced by a
URI.
NOTE: A default document uses a <Description>
element as its root node. The <Description> is named using
an about= attribute whose value is a URI. This URI MUST correspond
to the value in the rdf:resource= attribute in the <Defaults>
element in the referencing document. In the examples of default documents
below, the URLs of the external default values documents are used. However
the default resource URI does not have to be the document URL, as long as
the URI is uniquely identified, the same URI is used in both the source document
and the external default values document, and there is some way for the processing
software to locate and retrieve the document containing the default resource.
Examples of default documents referenced by the previous example are as follows:
Figure 3-6: External HardwarePlatform default
values
Document: http://example.com/HWDefault
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
<Description about="http://example.com/HWDefault">
<type resource="http://example.com/Schema#HardwarePlatform"/>
<prf:cpu>PPC</prf:cpu>
<prf:display>320x200</prf:display>
</Description>
</RDF>
|
Figure 3-7: External SoftwarePlatform default
values
Document: http://example.com/SWDefault
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
<Description about="http://example.com/SWDefault">
<type resource="http://example.com/Schema#SoftwarePlatform"/>
<prf:name>EPOC</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>2.0</prf:version>
</Description>
</RDF>
|
Figure 3-8: External BrowseUA default
values
Document: http://example.com/UADefault
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
<Description about="http://example.com/UADefault">
<type resource="http://example.com/Schema#BrowserUA"/>
<prf:name>Mozilla</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>5.0</prf:version>
<prf:htmlVersionsSupported>
<Bag>
<li>3.0</li>
<li>4.0</li>
</Bag>
</prf:htmlVersionsSupported>
</Description>
</RDF>
|
3.1.4 Distinguishing profile structure
from attributes
CC/PP uses namespaces to distinguish the vocabulary associated with the structure
(e.g. ccpp:component) from vocabularies associated with
applications (e.g. TerminalHardware, display).
The graph in figure 2-2a above can be described in RDF in a relatively straightforward
fashion. In this example we use the namespace "http://www.wapforum.org/UAPROF/ccppschema-20000405#"
to describe all the non-CC/PP properties:
Figure 3-9: XML serialization of CC/PP profile, with
namespaces
<?xml version="1.0"?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<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:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#">
<Description about="http://example.com/MyProfile">
<ccpp:component>
<Description about="http://example.com/TerminalHardware">
<type resource="http://example.com/Schema#HardwarePlatform" />
<prf:cpu>PPC</prf:cpu>
<prf:display>320x200</prf:display>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://example.com/TerminalSoftware">
<type resource="http://example.com/Schema#SoftwarePlatform" />
<prf:name>EPOC</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>2.0</prf:version>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://example.com/Browser">
<type resource="http://example.com/Schema#BrowserUA" />
<prf:name>Mozilla</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>5.0</prf:version>
<prf:htmlVersionsSupported>
<Bag>
<li>3.0</li>
<li>4.0</li>
</Bag>
</prf:htmlVersionsSupported>
</Description>
</ccpp:component>
</Description>
</RDF>
|
All RDF resources that relate to the overall structure of CC/PP are defined
in a specific namespace, and have certain associated schema properties that
allow them to be distinguished from attribute vocabulary or other RDF statements.
3.1.5 Notes on RDF usage
In this specification, names of RDF resource nodes are given by "about" so
they can be addressed from outside (i.e. from other RDF documents) when the
containing document does not have an assigned URI. (This is used for describing
proxy profile and capability chaining, when the profile information is contained
in a transitory unnamed protocol element.)
RDF Model and Syntax specification [3] defines two ways
to name RDF resources, namely "ID" and "about". RDF resources named by "about"
are fully identified, whereas those named by "ID" can not be referenced from
outside the containing document, unless some additional information is available
that allows the full (absolute) base URI to be determined. The RDF specification
is not currently clear about how a base URI should be determined [34].
The component resources in a profile are instances of components identified
in the corresponding schema, which in turn MUST be subclasses of ccpp:Component.
They MUST be identified as such, by means of the rdf:type
property whose value matches the name of the component type in the schema.
3.2 Proxy behavior
The proxy vocabulary defined here is not a mandatory part of the CC/PP specification,
but is defined here for use by CC/PP aware applications that may need to deal
with proxies or other intermediaries that play an active role in content handling.
Designers of CC/PP applications that need to deal with mediating behaviors
are strongly encouraged to use this vocabulary rather than define new structures.
For the purposes of this specification, a proxy is a component that sits on
the network path between a content consumer and a content provider, and modifies
or filters the content passed toward the consumer. This in turn affects what
the provider may send to a given client, so the consumer's CC/PP information
needs to be augmented with information corresponding to the proxy's behavior.
(For typical web access, the origin server is the provider, and the client is
the consumer.)
This approach to describing proxy behaviors does not force a proxy to analyze
and rewrite a client profile. Rather, the applicability, proxyAllow
and proxyBlock properties allow a proxy describe its behavior in a way
that takes account of a client's capabilities. As a result, the structure is
very easy for a proxy to create, though it does place some additional responsibility
on an origin server to analyze and combine the various parts appropriately.
The proxy description elements below are described using XML namespace local
parts, which are further qualified by the XML namespace identifier
<http://www.w3.org/2000/07/04-ccpp-proxy#>.
3.2.1 Capability chaining
A proxy's role as a content modifying component between client and server is represented
by chaining a description of the proxy's behavior to the profile supplied by
the outbound client or proxy. For any given request containing a CC/PP profile,
the proxy creates a new profile that refers to a CC/PP description of itself,
and to the CC/PP capability in the request it received. This new profile is passed
on towards the origin server.
A simple case is a client request that passes through a single proxy; the resulting
request profile received by the origin server looks like this:
-
Figure 3-10: Graph for client and single proxy
[<Request-profile>]
+--proxyProfile--> [<Proxy-profile>]
+--nextProfile---> [<Client-profile>]
|
A more complex case occurs when a request passes through several proxies,
each of which adds its own description to the overall profile:
Figure 3-11a: Graph for client and multiple proxies
[<Request-profile-n>]
+--proxyProfile--> [<Proxy-profile-n>]
+--nextProfile---> [<Request-profile-(n-1)>]
|
----------------
|
v
[<Request-profile-(n-1)>]
:
:
v
[<Request-profile-2>]
+--proxyProfile--> [<Proxy-profile-2>]
+--nextProfile---> [<Request-profile-1>]
|
----------------
|
v
[<Request-profile-1>]
+--proxyProfile--> [<Proxy-profile-1>]
+--nextProfile---> [<Client-profile>]
+--component--> [...]
:
(etc.)
|
This framework for proxy chaining uses the following RDF classes and properties,
defined by CC/PP.
- Profile:
- This class represents any CC/PP profile that
can be delivered to an origin server .
- Request-profile:
- This is a subclass of CCPP-profile
that is used to link a proxy profile to a request or client profile. Instances
of this are generally constructed on-the-fly as a request with a CC/PP profile
passes through proxies on its path toward an origin server. It combines a
client profile or another request profile with a proxy profile, and represents
the capabilities that the proxy can accept on behalf of the client that issued
the request. Because they are constructed for each request, these resources
are not usefully cacheable.
NOTE: the proxy profile referenced by this
item does not generally need to be constructed on-the-fly for each request.
- Proxy-profile:
- This class represents the capabilities and
filtering behavior of a given proxy. Instances of this class are generally
constructed statically for a given configured proxy system, and may usefully
be cached.
- Client-profile:
- This class represents the capabilities of
a given client. Instances of this class are generally constructed statically
for a given client system, and may usefully be cached.
- proxyProfile:
- This property is applied to a Request-profile
instance, and indicates a Proxy-profile that is applied to the CC/PP
profile associated with the corresponding request.
- nextProfile:
- This property is applied to a Request-profile
instance, and indicates a Request-profile or Client-profile
with which new proxy behavior is combined.
The corresponding XML might look like this:
Figure 3-11b: Request profile chain, XML
fragments
Proxy profile n:
<rdf:Description rdf:about="Proxy_n">
<rdf:type rdf:resource="Proxy-profile" />
<!-- Proxy_n profile properties here -->
:
</rdf:Description>
Request profile n:
<rdf:Description rdf:about="Request_n">
<rdf:type rdf:resource="Request-profile" />
<ccpp:proxyProfile rdf:resource="Proxy_n" />
<ccpp:nextProfile rdf:resource="Request_(n-1)" />
</rdf:Description>
:
Request profile 2:
<rdf:Description rdf:about="Request_2">
<rdf:type rdf:resource="Request-profile" />
<ccpp:proxyProfile rdf:resource="Proxy_2" />
<ccpp:nextProfile rdf:resource="Request_1" />
</rdf:Description>
Request profile 1:
<rdf:Description rdf:about="Request_1">
<rdf:type rdf:resource="Request-profile" />
<ccpp:proxyProfile rdf:resource="Proxy_1" />
<ccpp:nextProfile rdf:resource="Client" />
</rdf:Description>
Client profile:
<rdf:Description rdf:about="Client">
<rdf:type rdf:resource="ClientProfile" />
<ccpp:component>
:
</ccpp:component>
</rdf:Description>
|
3.2.2 Describing proxy behavior
A proxy may convert or interpret data for a client (add capabilities), or impose
policy constraints (block capabilities). E.g. a proxy might provide XHTML-to-WML
format conversion (which adds capabilities for clients that can render WML), or
may have a policy of disallowing any HTML content that contains JavaScript (which
blocks capabilities for clients that render HTML).
To describe such behavior, a proxy profile may contain three types of functional
component:
None of these are required in every case, but a proxy behavior description
without either proxyAllow or proxyBlock would be rather
pointless. Therefore, in practice, at least one of these should be present.
Thus, a proxy profile description looks something like this:
-
Figure 3-12: Graph describing proxy behavior
[<Proxy-profile>]
+--proxyBehavior--> [<Proxy-behavior>]
| +--applicability--> (Attribute(s)...)
| +--proxyAllow-----> (Attribute(s)...)
| +--proxyBlock-----> (Attribute(s)...)
|
+--proxyBehavior--> [<Proxy-behavior>]
| +--applicability--> (Attribute(s)...)
| +--proxyAllow-----> (Attribute(s)...)
| +--proxyBlock-----> (Attribute(s)...)
|
+--proxyBehavior--> [<Proxy-behavior>]
| :
:
(Repeat as needed for all proxy behaviors)
|
This framework for proxy behavior description uses the following RDF classes
and properties, defined by CC/PP.
- Proxy-profile:
- (See previous section.)
- Proxy-behavior:
- This class represents a description of a single
aspect of a proxy's behavior; e.g. a format conversion, or a specific capability-blocking
policy.
- proxyBehavior:
- This property is applied to a proxy capability
description, and references a Proxy-behavior instance.
- applicability:
- This property is applied to a Proxy-behavior
instance, and indicates a Component value with one or more attributes
indicating the requests to which the corresponding Proxy-behavior
applies. Each of the attributes thus specified must match attributes of a
request for the proxy behavior to be applicable to that request. Where an
attribute is set-valued, or if an attribute is repeated, the behavior applies
if any of the values supplied is matched by a corresponding attribute value
of the request. If the applicability property is not specified,
the corresponding Proxy-behavior can apply to any request.
- proxyAllow:
- This property is applied to a Proxy-behavior
instance, and indicates a Component value that specifies one or more
attribute values that are included by the corresponding Proxy-behavior
in the CC/PP capabilities of a request. These represent additional capabilities
that are supported by the proxy on behalf of a client (e.g. format conversion).
If no new attributes are allowed, this property should be omitted.
- proxyBlock:
- This property is applied to a Proxy-behavior
instance, and indicates a Component value that specifies one or more
capability attributes that are removed from the CC/PP capabilities of a request,
if present. These represent capabilities that are blocked by the proxy from
passing outbound to a client (e.g. content filtering). If no capabilities
are blocked, this property should be omitted.
Each (Attribute(s)...) entity indicated above consists of a Component
resource, whose precise type corresponds to a Component type of the applicable
request profile, and whose properties are ordinary CC/PP attribute identifiers
and values.
-
Figure 3-13a: Example 3.2.2.1 - graph
[<Proxy-profile>]
+--proxyBehavior--> [<Proxy-behavior>]
|
------------------
|
+--applicability-->[<Component>]
| |
| ----------------
| |
| +--uaprof:WmlVersion--> { "1.0", "1.1" }
|
+--proxyAllow----->[<Component>]
|
----------------
|
+--type----> { "text/xml", "application/xml"}
+--schema--> { "http://example.org/example/XHTML-1.0" }
|
This example effectively adds a capability to a profile to handle XHTML,
which is applicable if the request profile received from the outbound system
includes a capability to handle WML version 1.0 or 1.1. An RDF
representation of this is:
-
Figure 3-13b: Example 3.2.2.1 - RDF
<?xml version='1.0'?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2000/07/04-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'>
<!ENTITY ns-uaprof 'http://www.wapforum.org/UAPROF/ccppschema-20000405#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'
xmlns:ccpp-proxy = '&ns-ccpp-proxy;'
xmlns:ccpp-client = '&ns-ccpp-client;'
xmlns:uaprof = '&ns-uaprof;'>
<ccpp-proxy:Proxy-profile
rdf:about='http://www.example.com/proxy-profile-1'>
<ccpp-proxy:proxyBehavior>
<ccpp-proxy:Proxy-behavior>
<ccpp-proxy:applicability>
<ccpp:Component>
<uaprof:WmlVersion>
<rdf:Bag>
<rdf:li>1.0</rdf:li>
<rdf:li>1.1</rdf:li>
</rdf:Bag>
</uaprof:WmlVersion>
</ccpp:Component>
</ccpp-proxy:applicability>
<ccpp-proxy:proxyAllow>
<ccpp:Component>
<ccpp-client:type>
<rdf:Bag>
<rdf:li>text/xml</rdf:li>
<rdf:li>application/xml</rdf:li>
</rdf:Bag>
</ccpp-client:type>
<ccpp-client:schema>
<rdf:Bag>
<rdf:li>http://example.org/example/XHTML-1.0</rdf:li>
</rdf:Bag>
</ccpp-client:schema>
</ccpp:Component>
</ccpp-proxy:proxyAllow>
</ccpp-proxy:Proxy-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp-proxy:Proxy-profile>
</rdf:RDF>
|
-
Figure 3-14a: Example 3.2.2.2 -
graph
[<Proxy-profile>]
+--proxyBehavior----> [<Proxy-behavior>]
|
--------------------
|
+--applicability-->[<Component>]
| |
| ----------------
| |
| +--uaprof:WmlVersion--> { "1.0", "1.1" }
|
+--proxyAllow----->[<Component>]
|
----------------
|
+--type---------> { "text/xml", "application/xml"}
+--type---------> { "text/html", "application/html"}
+--schema-------> { "http://example.org/example/XHTML-1.0" }
+--uaprof:HTMLVersion--> { "3.2", "4.0" }
|
This example effectively adds a capability to a profile to handle HTML 3.2
or 4.0, or XHTML, which is applicable if the request profile received from
the outbound system includes a capability to handle WML version 1.0 or 1.1.
An RDF representation of this is:
-
Figure 3-14b: Example 3.2.2.2 - RDF
<?xml version='1.0'?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2000/07/04-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'>
<!ENTITY ns-uaprof 'http://www.wapforum.org/UAPROF/ccppschema-20000405#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'
xmlns:ccpp-proxy = '&ns-ccpp-proxy;'
xmlns:ccpp-client = '&ns-ccpp-client;'
xmlns:uaprof = '&ns-uaprof;'>
<ccpp-proxy:Proxy-profile
rdf:about='http://www.example.com/proxy-profile-2'>
<ccpp-proxy:proxyBehavior>
<ccpp-proxy:Proxy-behavior>
<ccpp-proxy:applicability>
<ccpp:Component>
<uaprof:WmlVersion>
<rdf:Bag>
<rdf:li>1.0</rdf:li>
<rdf:li>1.1</rdf:li>
</rdf:Bag>
</uaprof:WmlVersion>
</ccpp:Component>
</ccpp-proxy:applicability>
<ccpp-proxy:proxyAllow>
<ccpp:Component>
<ccpp-client:type>
<rdf:Bag>
<rdf:li>text/xml</rdf:li>
<rdf:li>application/xml</rdf:li>
</rdf:Bag>
</ccpp-client:type>
<ccpp-client:type>
<rdf:Bag>
<rdf:li>text/html</rdf:li>
<rdf:li>application/html</rdf:li>
</rdf:Bag>
</ccpp-client:type>
<ccpp-client:schema>
<rdf:Bag>
<rdf:li>http://example.org/example/XHTML-1.0</rdf:li>
</rdf:Bag>
</ccpp-client:schema>
<uaprof:HTMLVersion>
<rdf:Bag>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</uaprof:HTMLVersion>
</ccpp:Component>
</ccpp-proxy:proxyAllow>
</ccpp-proxy:Proxy-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp-proxy:Proxy-profile>
</rdf:RDF>
|
-
Figure 3-15a: Example 3.2.2.3 -
graph
[<Proxy-profile>]
+--proxyBehavior--> [<Proxy-behavior>]
|
------------------
|
+--proxyBlock--->[<Component>]
+--type---------> { "image/jpeg" }
|
This example effectively removes any capability to handle JPEG image files.
An RDF representation of this is:
-
Figure 3-15b: Example 3.2.2.3 - RDF
<?xml version='1.0'?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2000/07/04-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'
xmlns:ccpp-proxy = '&ns-ccpp-proxy;'
xmlns:ccpp-client = '&ns-ccpp-client;'>
<ccpp-proxy:Proxy-profile
rdf:about='http://www.example.com/proxy-profile-3'>
<ccpp-proxy:proxyBehavior>
<ccpp-proxy:Proxy-behavior>
<ccpp-proxy:proxyBlock>
<ccpp:Component>
<ccpp-client:type>
<rdf:Bag>
<rdf:li>image/jpeg</rdf:li>
</rdf:Bag>
</ccpp-client:type>
</ccpp:Component>
</ccpp-proxy:proxyBlock>
</ccpp-proxy:Proxy-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp-proxy:Proxy-profile>
</rdf:RDF>
|
-
Figure 3-16a: Example 3.2.2.4 -
graph
[<Proxy-profile>]
+--proxyBehavior----> [<Proxy-behavior>]
|
--------------------
|
+--applicability-->[<Component>]
| +--type---------> { "image/jpeg" }
+--proxyBlock----->[<Component>]
+--type---------> { "image/tiff" }
|
This example effectively removes any capability to handle TIFF image files,
and is applicable if the outbound request profile indicates capability to
handle JPEG. That is, always send JPEG in preference to TIFF, when possible.
An RDF representation of this is:
-
Figure 3-16b: Example 3.2.2.4 - RDF
<?xml version='1.0'?>
<!-- Checked by SiRPAC 1.16, 18-Jan-2001 -->
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2000/07/04-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
&nb |
