Composite Capability/Preference Profiles (CC/PP):
Structure and Vocabularies
- This version:
-
http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/
- Latest version:
-
http://www.w3.org/TR/CCPP-struct-vocab/
- Previous versions:
-
http://www.w3.org/TR/2001/WD-CCPP-struct-vocab-20010315/
- Editors:
- Graham Klyne, GK@acm.org,
Nine by Nine
- Franklin Reynolds,
franklin.reynolds@nokia.com, Nokia Research Center
- Chris Woodrow,
woodroc@metaphoria.net, Information Architects
- Hidetaka Ohto, ohto@w3.org,
W3C/Panasonic
- Mark H. Butler,
mark-h_butler@hp.com, Hewlett Packard
Copyright © 2002 W3C® (MIT, INRIA,
Keio), All Rights Reserved.
W3C
liability,
trademark, document
use, and software
licensing rules apply.
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,
- a non-normative 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 specification from the W3C CC/PP Working Group is a
Last Call Working Draft of the W3C.
The Working Group is part of the W3C Device 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 was created by merging C/PP
Structure and CC/PP
Vocabularies.
Following completion of Last Call, the CC/PP Working Group
has agreed to publish this public interim Working Draft incorporating
the resolution of all
last call issues
reported on the CC/PP Last Call Working Draft
published on 15 March 2001.
This Working Draft is a pre-version the Candidate Recommendation
document. Its goal is to show the work on disposition of comments
and allow authors of the Last Call comments to review the current CC/PP
specification before we advance to Candidate Recommendation. The two
weeks review will close on the 27th November 2002.
Please send comments and feedback to www-mobile@w3.org, the public forum
for discussion of W3C's work on Mobile Web Access. An archive is
available at
http://lists.w3.org/Archives/Public/www-mobile/.
On completion of the review, the CC/PP Working Group will
advance the specification to Candidate Recommendation according
to the following exit criteria, still under discussion:
- Sufficient reports of implementation experience have been gathered
to demonstrate that CC/PP Processors based on the specification
are implementable and have compatible behavior.
- An implementation report shows that there is at least one
implementation of each feature.
- Formal responses to all comments received by the Working Group.
Patent disclosures relevant to this specification may be
found on the CC/PP Working Group's patent disclosure page in
conformance with W3C policy.
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=' attributes, 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
[XMLNAMESPACES], and interoperability. There is a specification
that describes how to encode RDF using XML
[RDF], and another that defines an RDF schema description
language using RDF [RDFSCHEMA]. 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 CC/PP 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 optionally a 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 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 a simple CC/PP
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 [UAPROF] from the WAP
Forum. That is, any valid UAProf profile is intended to be a valid
CC/PP profile.
Although the examples and use to date have been focused on
device capabilities, CC/PP can also convey information about user
preferences that, used sensibly, should be allow web servers to
improve the accessibility of web sites. A fuller discussion of web
site accessibility can be found in the Web Content Accessibility
Guidelines [WAI].
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 be based on RDF classes and properties defined by the
RDF schema in appendix B (new CC/PP attributes sub-properties of
ccpp:Attribute, new client
components based on
ccpp:Component, etc.).
NOTE: The reason for requiring new vocabularies to
be based on the CC/PP schema is so that schema-aware applications
can include CC/PP profile data along with other RDF data. Having
new vocabulary terms based on the CC/PP schema means that they are
clearly identifiable as part of a CC/PP profile when RDF data from
multiple sources is combined. This requirement does not affect
stand-alone CC/PP profile processors, but the real value of using
RDF here will be in the longer term, allowing data from multiple
sources (e.g. document, security and privacy related information)
can be combined and processed by more general purpose handlers.
1.2 Structure of this
document
The remainder of this section covers terminology, conventions
and notations used in this document.
Section 2, CC/PP
architecture, provides an overview of the CC/PP
profile structure, use of XML namespaces, RDF data model and RDF
Schemas.
Section 3, CC/PP
structure, 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, Attribute
vocabularies, 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 [RFC2616].
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",
"MAY NOT", "REQUIRED", "RECOMMENDED" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3.2 RDF graph notation
The underlying structure of RDF is a directed labeled 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 labeled 'propertyName'
from an RDF resource named 'Subject-resource' to another RDF
resource named 'Object-resource'.
[Subject-resource] --propertyName--> "Property value"
Indicates a graph edge labeled '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"?>
<!-- Any RDF graph is an RDF element
-->
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns="http://www.example.com/schema#">
<!-- [Subject-resource] -propertyName-> [Object-resource]
-->
<rdf:Description
rdf:about="http://www.example.com/profile#Subject-resource">
<propertyName>
<rdf:Description
rdf:about="http://www.example.com/profile#Object-resource" />
</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> [Object-resource]
- (Alternative format)
-->
<rdf:Description
rdf:about="http://www.example.com/profile#Subject-resource">
<propertyName
rdf:resource="http://www.example.com/schema#Object-resource" />
</rdf:Description>
<!-- [Subject-resource] -propertyName-> "property value"
-->
<rdf:Description
rdf:about="http://www.example.com/profile#Subject-resource">
<propertyName>property value</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... }
-->
<rdf:Description
rdf:about="http://www.example.com/profile#Subject-resource">
<propertyName>
<rdf:Description>
<rdf:type
rdf: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="http://www.example.com/profile#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="http://www.example.com/schema#Subject-type" />
<propertyName>
<rdf:Description>
<rdf:type
rdf:resource="http://www.example.com/schema#Object-type" />
</rdf:Description>
</propertyName>
</rdf:Description>
<!-- [Subject-resource] -propertyName-> [Object-resource]
- |
- +-property1-> (val1)
- +-property2-> (val2)
- :
-->
<rdf:Description
rdf:about="http://www.example.com/profile#Subject-resource">
<propertyName>
<rdf:Description
rdf:about="http://www.example.com/profile#Object-resource" >
<property1>val1</property1>
<property2>val2</property2>
<!-- ...etc... -->
</rdf:Description>
</propertyName>
</rdf:Description>
</rdf: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 at least one or more
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
[example:Profile]
|
+--ccpp:component-->[example:TerminalHardware]
+--ccpp:component-->[example:TerminalSoftware]
+--ccpp:component-->[example:TerminalBrowser]
|
The corresponding XML might look like this:
Figure 2-1b: CC/PP profile components in
XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:example="http://www.example.com/schema#">
<rdf:Description rdf:about="http://www.example.com/profile#MyProfile">
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<!-- TerminalHardware properties here -->
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalSoftware">
<!-- TerminalSoftware properties here -->
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#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 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
[ex:MyProfile]
|
+--ccpp:component-->[ex:TerminalHardware]
| |
| +--rdf:type----> [ex:HardwarePlatform]
| +--ex:displayWidth--> "320"
| +--ex:displayHeight--> "200"
|
+--ccpp:component-->[ex:TerminalSoftware]
| |
| +--rdf:type----> [ex:SoftwarePlatform]
| +--ex:name-----> "EPOC"
| +--ex:version--> "2.0"
| +--ex:vendor---> "Symbian"
|
+--ccpp:component-->[ex:TerminalBrowser]
|
+--rdf:type----> [ex:BrowserUA]
+--ex:name-----> "Mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "Symbian"
+--ex: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"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#MyProfile">
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalSoftware">
<rdf:type
rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
<ex:name>EPOC</ex:name>
<ex:version>2.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalBrowser">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA" />
<ex:name>Mozilla</ex:name>
<ex:version>5.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
<ex:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</ex: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.
Default values for a component of a CC/PP profile are indicated
by a ccpp:default arc from the component
concerned to a component that describes the default values.
Figure 2-3a: CC/PP profile using
defaults
[ex:MyProfile]
|
+--ccpp:component--> [ex:TerminalHardware]
| |
| +--rdf:type-------> [ex:HardwarePlatform]
| +--ccpp:defaults--> [ex:HWDefault]
|
+--ccpp:component--> [ex:TerminalSoftware]
| |
| +--rdf:type-------> [ex:SoftwarePlatform]
| +--ccpp:defaults--> [ex:SWDefault]
|
+--ccpp:component--> [ex:TerminalBrowser]
|
+--rdf:type-------> [ex:BrowserUA]
+--ccpp:defaults--> [ex:UADefault]
[ex:HWDefault]
|
+--rdf:type----> [ex:HardwarePlatform]
+--ex:displayWidth--> "320"
+--ex:displayHeight--> "200"
[ex:SWDefault]
|
+--rdf:type----> [ex:SoftwarePlatform]
+--ex:name-----> "EPOC"
+--ex:version--> "2.0"
+--ex:vendor---> "Symbian"
[ex:UADefault]
|
+--rdf:type----> [ex:BrowserUA]
+--ex:name-----> "Mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "Symbian"
+--ex: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"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#MyProfile">
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/schema#HWDefault" />
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalSoftware">
<rdf:type
rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/schema#SWDefault" />
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalBrowser">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA" />
<ccpp:defaults
rdf:resource="http://www.example.com/schema#UADefault" />
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
Defaults for HardwarePlatform:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#HWDefault">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
</rdf:Description>
</rdf:RDF>
Defaults for SoftwarePlatform:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#SWDefault">
<rdf:type
rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
<ex:name>EPOC</ex:name>
<ex:version>2.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
</rdf:Description>
</rdf:RDF>
Defaults for BrowserUA:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#UADefault">
<rdf:type
rdf:resource="http://www.example.com/schema#BrowserUA" />
<ex:name>Mozilla</ex:name>
<ex:version>5.0</ex:version>
<ex:vendor>Symbian</ex:vendor>
<ex:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</ex: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
[ex:MyProfile]
|
+--ccpp:component--> [ex:TerminalHardware]
|
+--rdf:type--------> [ex:HardwarePlatform]
+--ccpp:defaults---> [ex:HWDefault]
+--ex:memory-------> "32Mb"
[ex:HWDefault]
|
+--rdf:type----> [ex:HardwarePlatform]
+--ex:displayWidth--> "320"
+--ex:displayHeight--> "200"
+--ex: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"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#MyProfile">
<ccpp:component>
<rdf:Description
rdf:about="http://www.example.com/profile#TerminalHardware">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/schema#HWDefault" />
<ex:memory>32Mb</ex:memory>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
Defaults for HardwarePlatform:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ex="http://www.example.com/schema#">
<rdf:Description
rdf:about="http://www.example.com/profile#HWDefault">
<rdf:type
rdf:resource="http://www.example.com/schema#HardwarePlatform" />
<ex:displayWidth>320</ex:displayWidth>
<ex:displayHeight>200</ex:displayHeight>
<ex:memory>16Mb</ex: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.
In CC/PP, support for proxies is optional. 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:
[ex:ClientProfile]
|
+--ccpp:component-->[ex:TerminalHardware]
| |
| +--rdf:type----> [ex:HardwarePlatform]
| +--ex:displayWidth--> "320"
| +--ex:displayHeight--> "200"
|
+--ccpp:component-->[ex:TerminalSoftware]
| |
| +--rdf:type----> [ex:SoftwarePlatform]
| +--ex:name-----> "EPOC"
| +--ex:version--> "2.0"
| +--ex:vendor---> "Symbian"
|
+--ccpp:component-->[ex:TerminalBrowser]
|
+--rdf:type----> [ex:BrowserUA]
+--ex:name-----> "Mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "Symbian"
+--ex:htmlVersionsSupported--> { "3.0","4.0" }
Proxy Profile:
[ex:ProxyProfile]
|
+--ccpp:proxyBehavior--> [ ]
|
+--ccpp:proxyAllow--> [ex:Proxy]
|
----------------
|
+--rdf:type---> [ProxyComponent]
+--ex:name----> "PhoneTranscoder"
+--ex:vendor--> "SuperProxy"
+--ex:version-> "1.0"
+--ex:html4.0towml1.1--> "Yes"
Request Profile:
[ex:RequestProfile]
|
+--ex:nextProfile---> [ex:ClientProfile]
+--ex:proxyProfile--> [ex: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 a 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
[ex:Request-profile-n]
+--ccpp:proxyProfile--> [ex:Proxy-profile-n]
+--ccpp:nextProfile---> [ex:Request-profile-(n-1)]
|
--------------------
|
v
[ex:Request-profile-(n-1)]
:
:
v
[ex:Request-profile-2]
+--ccpp:proxyProfile--> [ex:Proxy-profile-2]
+--ccpp:nextProfile---> [ex:Request-profile-1]
|
--------------------
|
v
[ex:Request-profile-1]
+--ccpp:proxyProfile--> [ex:Proxy-profile-1]
+--ccpp:nextProfile---> [ex:Client-profile]
+--ccpp:component--> [...]
|
An XML version of this is presented in section 3.2.1.
Interpretation of the structures used to describe proxy
behavior is described in section
3.2.
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
[RFC2534], and serves as an example of how CC/PP attribute
vocabularies may be defined. Another such example is the WAP Forum
UAProf specification [UAPROF].
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 [XMLNAMESPACES] 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:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">
|
The first namespace declaration is for RDF usage. The second
declaration names the CC/PP core structural vocabulary, which
includes "component", "defaults" and
other properties that are intrinsic to the CC/PP framework. The
third namespace declaration names a component CC/PP properties
vocabulary.
NOTE: remember that the namespace prefixes are
quite arbitrary: applications MUST NOT assume that the prefix
rdf: refers to the RDF vocabulary, or that
ccpp: refers to the intrinsic CC/PP vocabulary, etc. It is
the URI to which a namespace prefix is bound that matters.
NOTE: although namespace names are identified by
URI references, there is no requirement that a schema be available
at that URI. In the above example, the UAProf namespace name is
"http://www.wapforum.org/UAPROF/ccppschema-20000405#"
yet there is no schema at that URI. It is generally preferred
practice that a corresponding schema exists at the URL used to
identify a namespace, but this is not a requirement and CC/PP
applications should not assume that such a schema will exist.
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/2002/11/08-ccpp#
RDF class declarations for CC/PP, and core structural
properties.
http://www.w3.org/2002/11/08-ccpp-proxy#
Optional vocabulary for describing proxy behaviors in a
CC/PP profile.
http://www.w3.org/2002/11/08-ccpp-client#
Example but non-normative vocabulary for describing
simple client capabilities, with particular relevance to print and
display clients.
NOTE: to retrieve these schemas it is necessary
for your browser to add the header Accept:text/xml in
the request. Browsers such that do not add this accept header or
use the header Accept:*/* or variants thereof will
receive a HTML page that notes these are namespaces reserved for
the CC/PP Schemas.
2.3 RDF background
This section provides some introductory background to RDF. RDF
is formally defined in the RDF Model and Syntax
specification [RDF].
See also sections 3.1.4
and 3.1.5, which give information about the
way RDF is used for representing a CC/PP profile.
The foundation of RDF is a directed labeled 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 [CONCEPTUAL]. A
broader background to knowledge representation issues can be found
in Sowa's book Knowledge Representation [KNOWLEDGE]. 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 labeled 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
fragment IDs (see RFC2396 [RFC2396]).
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, and 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 [RDFSCHEMA].
- 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 data type defined by XML. In RDF terms, a
literal may have content that is XML markup but is not further
evaluated by the RDF processor.
An RDF graph is expressed in XML using syntax described in the
RDF Model and Syntax specification
[RDF].
An RDF subject resource and a number of associated properties is
contained in an <rdf:Description>
element, with an rdf:ID or
rdf:about 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 identifying a resource that is described
elsewhere:
Figure 2-9a: XML fragment containing RDF
resource description
<rdf:Description rdf:about="http://example.com/MyProfile">
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalHardware">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
<prf:cpu>PPC</prf:cpu>
<prf:displayWidth>320</prf:displayWidth>
<prf:displayHeight>200</prf:displayHeight>
</rdf:Description>
</ccpp:component>
</rdf: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/TerminalHardware]
|
-----------------
|
+--rdf:type-------> [http://example.com/Schema#HardwarePlatform]
+--prf:cpu--------> "PPC"
+--prf:displayWidth----> "320"
+--prf:displayHeight----> "200"
|
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"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:prf="http://example.com/schema#">
<rdf:Description rdf:about="http://example.com/MyProfile">
<ccpp:component>
<rdf:Description
rdf:about="http://example.com/profile#TerminalHardware">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" />
<prf:cpu>PPC</prf:cpu>
<prf:displayWidth>320</prf:displayWidth>
<prf:displayHeight>200</prf:displayHeight>
</rdf:Description>
</ccpp:component>
<!-- ...etc... -->
</rdf:Description>
</rdf: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 XML attributes within
<rdf:Description> elements to represent literal
property values, and
- use of
rdf:resource within a property
element to indicate a resource value, together with additional XML
attributes to indicate literal properties of the indicated
resource.
The first of these abbreviated forms is often used to construct
RDF serialization that looks similar to commonly used XML formats.
Using this, the inner <rdf:Description>
of the above example would become:
Figure 2-11: RDF 'type' abbreviation
syntax
<prf:HardwarePlatform
rdf:about="http://example.com/profile#TerminalHardware">
<prf:cpu>PPC</prf:cpu>
<prf:displayWidth>320</prf:displayWidth>
<prf:displayHeight>200</prf:displayHeight>
</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 [RDFSCHEMA].
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).
Specific 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.
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.
Figure 2-12: Constraints in RDF
Schema
 |
Refer to the RDF Schema specification
[RDFSCHEMA] 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 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. No more than one instance of a component type should
be present for any given profile resource.
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
[RDF]. 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
labeled 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-1: RDF statement describing a
client attribute
[Client component resource] --attributeName--> (Attribute-value)
|
CC/PP attribute labels are represented by XML name values (per
XML specification [XML], section 2.3), which
may include a namespace prefix (i.e. a qualified name, per
XML namespaces [XMLNAMESPACES], section 3).
When combined with the corresponding namespace or default namespace
declaration, each label can be mapped to a URI. Thus, CC/PP
attribute names are URIs, with XML namespace syntax used to avoid
some of the RDF expressions becoming too cumbersome.
Attribute values may be of simple or structured data types.
Simple data types are discussed in the section 4.1.1. 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
[CCPPCOMPARISON].
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 4.1.2.
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 [RDF], 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-2a: CC/PP profile using
defaults
[ex:MyProfile]
|
+--ccpp:component--> [ex:TerminalHardware]
| |
| +--rdf:type-------> [ex:HardwarePlatform]
| +--ccpp:defaults--> [ex:HWDefault]
| +--ex:displayWidth--> "640"
| +--ex:displayHeight-> "400"
|
+--ccpp:component--> [ex:TerminalSoftware]
| |
| +--rdf:type-------> [ex:SoftwarePlatform]
| +--ccpp:defaults--> [ex:SWDefault]
|
+--ccpp:component--> [ex:TerminalBrowser]
|
------------
|
+--rdf:type-------> [ex:BrowserUA]
+--ccpp:defaults--> [ex:UADefault]
+--ex:htmlVersionsSupported--> { "3.0", "4.0", "XHTML" }
[ex:HWDefault]
|
+--rdf:type----> [ex:HardwarePlatform]
+--ex:cpu------> "PPC"
+--ex:displayWidth--> "320"
+--ex:displayHeight--> "200"
[ex:SWDefault]
|
+--rdf:type----> [ex:SoftwarePlatform]
+--ex:name-----> "EPOC"
+--ex:version--> "2.0"
+--ex:vendor---> "Symbian"
[ex:UADefault]
|
+--rdf:type----> [ex:BrowserUA]
+--ex:name-----> "Mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "Symbian"
+--ex:htmlVersionsSupported--> { "3.0", "4.0" }
|
If a component referenced by ccpp:default
contains an attribute that is not present on the referencing
profile component, then the effect is as if the attribute value in
the default component is applied directly to the profile component.
For example the profile in Figure 3-2a should be interpreted as
describing the same capabilities as shown in Figure 3-2b.
Figure 3-2b: Resolving a CC/PP profile
using defaults
[ex:MyProfile]
|
+--ccpp:component--> [ex:TerminalHardware]
| |
| +--rdf:type-------> [ex:HardwarePlatform]
| +--ex:displayWidth--> "640"
| +--ex:displayHeight-> "400"
| +--ex:cpu------> "PPC"
|
+--ccpp:component--> [ex:TerminalSoftware]
| |
| +--rdf:type-------> [ex:SoftwarePlatform]
| +--ex:name-----> "EPOC"
| +--ex:version--> "2.0"
| +--ex:vendor---> "Symbian"
|
+--ccpp:component--> [ex:TerminalBrowser]
|
------------
|
+--rdf:type-------> [ex:BrowserUA]
+--ex:htmlVersionsSupported--> { "3.0", "4.0", "XHTML" }
+--ex:name-----> "Mozilla"
+--ex:version--> "5.0"
+--ex:vendor---> "Symbian"
|
And here is the corresponding XML serialization, with the
default resource descriptions coded inline in the client profile
description. Note that this example uses a default namespace for
RDF elements, but still must use explicit namespace prefixes for
RDF attributes.
Figure 3-2c: CC/PP profile using inline
defaults, in XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:prf="http://example.com/Schema#">
<rdf:Description rdf:about="http://example.com/MyProfile">
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalHardware">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/>
<ccpp:defaults>
<rdf:Description rdf:about="http://example.com/HWDefault">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/>
<prf:cpu>PPC</prf:cpu>
<prf:displayWidth>320</prf:displayWidth>
<prf:displayHeight>200</prf:displayHeight>
</rdf:Description>
</ccpp:defaults>
<prf:displayHeight>640</prf:displayHeight>
<prf:displayWidth>400</prf:displayWidth>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalSoftware">
<rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform" />
<ccpp:defaults>
<rdf:Description rdf:about="http://example.com/SWDefault">
<rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/>
<prf:name>EPOC</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>2.0</prf:version>
</rdf:Description>
</ccpp:defaults>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://example.com/Browser">
<rdf:type rdf:resource="http://example.com/Schema#BrowserUA" />
<ccpp:defaults>
<rdf:Description rdf:about="http://example.com/UADefault">
<rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/>
<prf:name>Mozilla</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>5.0</prf:version>
<prf:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</prf:htmlVersionsSupported>
</rdf:Description>
</ccpp:defaults>
<prf:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
<rdf:li>XHTML</rdf:li>
</rdf:Bag>
</prf:htmlVersionsSupported>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
|
Inline defaults are logically equivalent to defaults contained
in an external referenced document, and such external documents
would be a normal way of providing default values. The following is
the XML serialization of the same profile with references to
externally defined defaults:
Figure 3-3: CC/PP profile referencing
externally defined defaults, in XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:prf="http://example.com/Schema#">
<rdf:Description rdf:about="http://example.com/MyProfile">
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalHardware">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/>
<ccpp:defaults rdf:resource="http://example.com/HWDefault"/>
<prf:displayWidth>640</prf:displayWidth>
<prf:displayHeight>400</prf:displayHeight>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalSoftware">
<rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform" />
<ccpp:defaults rdf:resource="http://example.com/SWDefault"/>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://example.com/Browser">
<rdf:type rdf:resource="http://example.com/Schema#BrowserUA" />
<ccpp:defaults rdf:resource="http://example.com/UADefault"/>
<prf:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
<rdf:li>XHTML</rdf:li>
</rdf:Bag>
</prf:htmlVersionsSupported>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
|
Each external defaults resource is a separate RDF document
referenced by a URI.
NOTE: A default document uses a
<rdf:Description> element as its root node. The
<rdf:Description> is named using an
rdf:about whose value is a URI. This URI MUST
correspond to the value of the rdf:resource XML
attribute in the <ccpp:defaults> element
in the referencing document. (The default component does not need
to be identified when it occurs inline, as in the first example
above.) 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-4: External HardwarePlatform
default values
Document: http://example.com/HWDefault
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:prf="http://example.com/Schema#">
<rdf:Description rdf:about="http://example.com/HWDefault">
<rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/>
<prf:cpu>PPC</prf:cpu>
<prf:displayWidth>320</prf:displayWidth>
<prf:displayHeight>200</prf:displayHeight>
</rdf:Description>
</rdf:RDF>
|
Figure 3-5: External SoftwarePlatform
default values
Document: http://example.com/SWDefault
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:prf="http://example.com/Schema#">
<rdf:Description rdf:about="http://example.com/SWDefault">
<rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/>
<prf:name>EPOC</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>2.0</prf:version>
</rdf:Description>
</rdf:RDF>
|
Figure 3-6: External BrowseUA default
values
Document: http://example.com/UADefault
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:prf="http://example.com/Schema#">
<rdf:Description rdf:about="http://example.com/UADefault">
<rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/>
<prf:name>Mozilla</prf:name>
<prf:vendor>Symbian</prf:vendor>
<prf:version>5.0</prf:version>
<prf:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</prf:htmlVersionsSupported>
</rdf:Description>
</rdf: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).
In this example we use the namespace
"http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#",
associated with prefix "prf:", to describe all the
non-RDF and non-CC/PP properties:
Figure 3-7: XML serialization of CC/PP
profile, with namespaces
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2002/11/08-ccpp#"
xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">
<rdf:Description rdf:about="http://example.com/MyProfile">
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalHardware">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#HardwarePlatform" />
<prf:CPU>PPC</prf:CPU>
<prf:ScreenSize>320x200</prf:ScreenSize>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://example.com/TerminalSoftware">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#SoftwarePlatform" />
<prf:OSName>EPOC</prf:OSName>
<prf:OSVendor>Symbian</prf:OSVendor>
<prf:OSVersion>2.0</prf:OSVersion>
</rdf:Description>
</ccpp:component>
<ccpp:component>
<rdf:Description rdf:about="http://example.com/Browser">
<rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#BrowserUA" />
<prf:BrowserName>Mozilla</prf:BrowserName>
<prf:BrowserVersion>5.0</prf:BrowserVersion>
<prf:HtmlVersion>
<rdf:Bag>
<rdf:li>3.0</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</prf:HtmlVersion>
</rdf:Description>
</ccpp:component>
</rdf:Description>
</rdf:RDF>
|
All RDF resources that relate to the overall structure of CC/PP
are defined in the ccpp:
namespace, and have associated schema properties that allow them to
be distinguished from attribute vocabulary or other RDF statements
by a schema-aware processor.
3.1.5 Notes on RDF usage
This specification uses "rdf:about" to specify the
URI's of resources. This was a deliberate choice to ensure that
such URI's are absolutely and unambiguously specified. This is also
a different to UAProf, which uses both "rdf:about" and
"rdf:ID".
CC/PP allows "rdf:ID" attributes or
"rdf:about" attributes. However, the values of
"rdf:ID" attributes represent URI's which are relative
to the base URI of the document [34]. When
a document is moved to another location on the web the meaning of
the value of an "rdf:ID" attribute changes. The
meaning is undefined when the RDF is contained in a document with
no base URI, e.g. when encapsulated in a message. The RDFCore WG
have a Working Draft [RDFXML] that proposes
that RDF should support "xml:base" attributes. If this
addition to RDF achieves recommendation status, then it would be
appropriate to use "rdf:ID" attributes in conjunction
with an "xml:base" attribute instead of
"rdf:about" attributes. For now we recommend that
CC/PP profiles SHOULD use "rdf:about" and that the
URI's of resources are fully specified.
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
may usefully be identified as such, by means of the
rdf:type property whose value matches the
name of the component type in the schema. (Sometimes this type
indication MUST be present: see
section 3.1.1, Components.)
The RDF statements that make up an RDF graph do not necessarily
occur in a single document. For CC/PP, the profile delivered may
contain references to RDF subgraphs that are transferred
separately, or are retrieved from designated Web resources.
When an external sub-graph is referenced in this way, the effect
is equivalent to taking the sets of RDF statement "triples"
described by the referencing document and the referenced document,
and constructing a new document that describes the union of these
sets. (NOTE: implementations are not
required to actually construct such a document, just to interpret
the RDF statements as they would from a single document.)
This composition of multiple RDF documents presumes that the
content of the referenced document is trusted to accurately
represent the capabilities that are presented to the sender of some
resource data. Accordingly, such composition is restricted to
documents describing resources referenced by properties whose
intended interpretation embodies such a notion of trust;
viz. ccpp:defaults,
ccpp:nextProfile and
ccpp:proxyProfile.
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.). The proxy behavior description is
intended for use by intermediaries whose operational
characteristics match those described in Appendix F of this
document.
A proxy profile describes the effect of a proxy using
proxyAllow and proxyBlock properties, in terms of how it
modifies what the origin sender can send and have it usable by the
client. The applicability property can be used as a sort of
matching rule to indicate which clients are affected by the
proxyAllow and proxyBlock properties. Proxy profiles
have a simple structure, and can be created for each proxy without
regard for the client profiles with which they may be used.
A CC/PP proxy does not modify the client profile in any way, but
creates a profile that describes the effect of its own behavior.
The origin server then has responsibility for analyzing the client
profile and each, if any, associated proxy profile to determine
what sort of content is appropriate to send. The order in which
proxies are encountered can have an effect on end-to-end behavior,
and a "capability chaining" mechanism reflects the order in which
proxies are encountered.
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/2002/11/08-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 client or proxy on the
outbound side. 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-8: Graph for client and single
proxy
[<ccpp:Request-profile>]
+--ccpp-proxy:proxyProfile--> [<ccpp:Proxy-profile>]
+--ccpp-proxy:nextProfile---> [<ccpp: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-9a: Graph for client and multiple
proxies
[ex:Request-profile-n]
+--ccpp-proxy:proxyProfile--> [ex:Proxy-profile-n]
+--ccpp-proxy:nextProfile---> [ex:Request-profile-(n-1)]
|
--------------------------
|
v
[ex:Request-profile-(n-1)]
:
:
v
[ex:Request-profile-2]
+--ccpp-proxy:proxyProfile--> [ex:Proxy-profile-2]
+--ccpp-proxy:nextProfile---> [ex:Request-profile-1]
|
-------------------------
|
v
[ex:Request-profile-1]
+--ccpp-proxy:proxyProfile--> [ex:Proxy-profile-1]
+--ccpp-proxy:nextProfile---> [ex:Client-profile]
|
-------------------------
|
+--ccpp: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, and may be referenced by multiple
requests. By contrast, a request profile is always unique to a
single proxy-chain position in a CC/PP profile.
- 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-9b: Request profile chain, XML
fragments
Proxy profile n:
<rdf:Description rdf:about="http://example.com/Proxy_n">
<rdf:type
rdf:resource="http://www.w3.org/2002/11/08-ccpp#Proxy-profile" />
<!-- Proxy_n profile properties here -->
:
</rdf:Description>
Request profile n:
<rdf:Description rdf:about="http://example.com/Request_n">
<rdf:type
rdf:resource="http://www.w3.org/2002/11/08-ccpp#Request-profile" />
<ccpp:proxyProfile rdf:resource="http://example.com/Proxy_n" />
<ccpp:nextProfile rdf:resource="http://example.com/Request_(n-1)" />
</rdf:Description>
:
Request profile 2:
<rdf:Description rdf:about="http://example.com/Request_2">
<rdf:type
rdf:resource="http://www.w3.org/2002/11/08-ccpp#Request-profile" />
<ccpp:proxyProfile rdf:resource="http://example.com/Proxy_2" />
<ccpp:nextProfile rdf:resource="http://example.com/Request_1" />
</rdf:Description>
Request profile 1:
<rdf:Description rdf:about="http://example.com/Request_1">
<rdf:type
rdf:resource="http://www.w3.org/2002/11/08-ccpp#Request-profile" />
<ccpp:proxyProfile rdf:resource="http://example.com/Proxy_1" />
<ccpp:nextProfile rdf:resource="http://example.com/Client" />
</rdf:Description>
Client profile:
<rdf:Description rdf:about="http://example.com/Client">
<rdf:type
rdf:resource="http://www.w3.org/2002/11/08-ccpp#ClientProfile" />
<ccpp:component>
:
</ccpp:component>
</rdf:Description>
|
A valid CC/PP profile MUST NOT contain any loop in the request
chain, and the request chain MUST terminate in a client
profile.
NOTE: it has been suggested that the proxy
profiles may be linked directly, rather than using the separate
<ccpp:Request-profile> resources. But
there is no fundamental reason why the same proxy profile may not
appear more than once in a request chain, and direct linking in
these circumstances would lead to looping of the chain. Hence
separate link resources are used.
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-10: Graph describing proxy
behavior
[<ccpp:Proxy-profile>]
+--ccpp-proxy:proxyBehavior--> [<Proxy-behavior>]
| |
| ---------------------
| |
| +--ccpp-proxy:applicability--> (Attribute(s)...)
| +--ccpp-proxy:proxyAllow-----> (Attribute(s)...)
| +--ccpp-proxy:proxyBlock-----> (Attribute(s)...)
|
+--ccpp-proxy:proxyBehavior--> [<Proxy-behavior>]
| |
| ---------------------
| |
| +--ccpp-proxy:applicability--> (Attribute(s)...)
| +--ccpp-proxy:proxyAllow-----> (Attribute(s)...)
| +--ccpp-proxy:proxyBlock-----> (Attribute(s)...)
|
+--ccpp-proxy: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
applicable to that component type. All attributes referenced by a
single ccpp:Proxy-behavior instance MUST be
instances of the same component type. For example, it is
not permitted for
ccpp-proxy:applicability to refer to a
prf:HardwarePlatform component, and a
ccpp-proxy:proxyAllow of the same
ccpp:Proxy-behavior to refer to a
prf:SoftwarePlatform component.
If a Component has any properties that may be applied to
more than one component type, its component type MUST be indicated
by an rdf:type property. In any case, the type
of any Component referenced in a
ccpp:Proxy-behavior description SHOULD be
indicated by an rdf:type property.
In a proxy capability description, 'applicability', 'proxyAllow'
and 'proxyBlock' are all presumed to refer to capabilities and
preferences using the same attribute vocabulary. It is particularly
significant that an 'applicability' value uses vocabulary in common
with the client profile.
But note that a proxy may introduce a capability that is
otherwise unknown to the client (e.g. file format transcoding), in
which case an attribute vocabulary term must be used that does not
appear in the client's profile, and which may not be recognized or
understood by the client system. This idea is illustrated by
example 3.2.2.1.
Similarly, a proxy may unconditionally block capabilities which
the client does not declare (e.g. file format blocking), in which a
proxy-block may mention an attribute that does not appear in the
client profile. This is illustrated by example 3.2.2.3.
Figure 3-11a: Example 3.2.2.1 -
graph
[<ccpp:Proxy-profile>]
+--ccpp-proxy:proxyBehavior--> [<ccpp:Proxy-behavior>]
|
----------------------------
|
+--ccpp-proxy:applicability-->[<ccpp:Component>]
| |
| ---------------------------
| |
| +--prf:WmlVersion--> { "1.0", "1.1" }
|
+--ccpp-proxy:proxyAllow----->[<ccpp:Component>]
|
---------------------------
|
+--ccpp-client:type----> { "text/xml", "application/xml"}
+--ccpp-client: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 system on the outbound side includes a capability to
handle WML version 1.0 or 1.1. An RDF representation of this
is:
Figure 3-11b: Example 3.2.2.1 -
RDF
<?xml version='1.0'?>
<!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/2002/11/08-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2002/11/08-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-ccpp-client#'>
<!ENTITY ns-uaprof 'http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#'>
]>
<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:prf = '&ns-uaprof;'>
<ccpp:Proxy-profile
rdf:about='http://www.example.com/Proxy-profile-1'>
<ccpp-proxy:proxyBehavior>
<ccpp:Proxy-behavior>
<ccpp-proxy:applicability>
<ccpp:Component>
<prf:WmlVersion>
<rdf:Bag>
<rdf:li>1.0</rdf:li>
<rdf:li>1.1</rdf:li>
</rdf:Bag>
</prf: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 rdf:resource="http://example.org/example/XHTML-1.0"/>
</rdf:Bag>
</ccpp-client:schema>
</ccpp:Component>
</ccpp-proxy:proxyAllow>
</ccpp:Proxy-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp:Proxy-profile>
</rdf:RDF>
|
Figure 3-12a: Example 3.2.2.2 -
graph
[<ccpp:Proxy-profile>]
+--ccpp-proxy:proxyBehavior----> [<ccpp:Proxy-behavior>]
|
------------------------------
|
+--ccpp-proxy:applicability-->[<ccpp:Component>]
| |
| ---------------------------
| |
| +--prf:WmlVersion---> { "1.0", "1.1" }
|
+--ccpp-proxy:proxyAllow----->[<ccpp:Component>]
|
---------------------------
|
+--ccpp-client:type----> { "text/xml", "application/xml",
| "text/html", "application/html" }
+--ccpp-client:schema--> { [http://example.org/example/XHTML-1.0] }
+--prf: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 system on the outbound side
includes a capability to handle WML version 1.0 or 1.1. An RDF
representation of this is:
Figure 3-12b: Example 3.2.2.2 -
RDF
<?xml version='1.0'?>
<!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/2002/11/08-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2002/11/08-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-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:prf = '&ns-uaprof;'>
<ccpp:Proxy-profile
rdf:about='http://www.example.com/proxy-profile-2'>
<ccpp-proxy:proxyBehavior>
<ccpp:Proxy-behavior>
<ccpp-proxy:applicability>
<ccpp:Component>
<prf:WmlVersion>
<rdf:Bag>
<rdf:li>1.0</rdf:li>
<rdf:li>1.1</rdf:li>
</rdf:Bag>
</prf: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 rdf:resource="http://example.org/example/XHTML-1.0"/>
</rdf:Bag>
</ccpp-client:schema>
<prf:HTMLVersion>
<rdf:Bag>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</prf:HTMLVersion>
</ccpp:Component>
</ccpp-proxy:proxyAllow>
</ccpp:Proxy-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp:Proxy-profile>
</rdf:RDF>
|
Figure 3-13a: Example 3.2.2.3 -
graph
[<ccpp:Proxy-profile>]
+--ccpp-proxy:proxyBehavior--> [<ccpp:Proxy-behavior>]
|
----------------------------
|
+--ccpp-proxy:proxyBlock---> [<ccpp:Component>]
|
--------------------------
|
+--ccpp-client:type--> { "image/jpeg" }
|
This example effectively removes any capability to handle JPEG
image files. An RDF representation of this is:
Figure 3-13b: Example 3.2.2.3 -
RDF
<?xml version='1.0'?>
<!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/2002/11/08-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2002/11/08-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-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-profile
rdf:about='http://www.example.com/proxy-profile-3'>
<ccpp-proxy:proxyBehavior>
<ccpp: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-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp:Proxy-profile>
</rdf:RDF>
|
Figure 3-14a: Example 3.2.2.4 -
graph
[<ccpp:Proxy-profile>]
+--ccpp-proxy:proxyBehavior--> [<ccpp:Proxy-behavior>]
|
----------------------------
|
+--ccpp-proxy:applicability-->[<ccpp:Component>]
| |
| ---------------------------
| |
| +--ccpp-client:type--> { "image/jpeg" }
|
+--ccpp-proxy:proxyBlock----->[<ccpp:Component>]
|
---------------------------
|
+--ccpp-client:type--> { "image/tiff" }
|
This example effectively removes any capability to handle TIFF
image files, and is applicable if the request profile from the
outbound side indicates capability to handle JPEG. That is, always
send JPEG in preference to TIFF, when possible. An RDF
representation of this is:
Figure 3-14b: Example 3.2.2.4 -
RDF
<?xml version='1.0'?>
<!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/2002/11/08-ccpp#'>
<!ENTITY ns-ccpp-proxy 'http://www.w3.org/2002/11/08-ccpp-proxy#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-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-profile
rdf:about='http://www.example.com/proxy-profile-4'>
<ccpp-proxy:proxyBehavior>
<ccpp:Proxy-behavior>
<ccpp-proxy:applicability>
<ccpp:Component>
<ccpp-client:type>
<rdf:Bag>
<rdf:li>image/jpeg</rdf:li>
</rdf:Bag>
</ccpp-client:type>
</ccpp:Component>
</ccpp-proxy:applicability>
<ccpp-proxy:proxyBlock>
<ccpp:Component>
<ccpp-client:type>
<rdf:Bag>
<rdf:li>image/tiff</rdf:li>
</rdf:Bag>
</ccpp-client:type>
</ccpp:Component>
</ccpp-proxy:proxyBlock>
</ccpp:Proxy-behavior>
</ccpp-proxy:proxyBehavior>
</ccpp:Proxy-profile>
</rdf:RDF>
|
4. Attribute
vocabularies
4.1 Attribute data
This section describes the basic data types and data structuring
options that are available for the values associated with a CCPP
attribute.
All CC/PP attributes should be defined with values that can be
treated as one of the simple or complex data types discussed later.
Support for the described formats for attribute values is
RECOMMENDED; this specification does not prohibit the use of other
valid RDF forms, but provides no guidance for their interpretation.
(See also section 1.1 and Appendix
F.)