Composite Capability/Preference Profiles (CC/PP):
Structure and Vocabularies
- This version:
- http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/
- Latest version:
- http://www.w3.org/TR/CCPP-struct-vocab/
- Previous versions:
- http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/
- 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
- Johan Hjelm, Johan.hjelm@ericsson.com,
Ericsson
- Mark H. Butler, mark-h_butler@hp.com,
Hewlett-Packard
- Luu Tran, luu.tran@sun.com, Sun
Microsystems
Copyright © 2003 W3C® (MIT, ERCIM,
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, 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:
- the types of values to which CC/PP attributes may refer,
- an appendix describing how to introduce new vocabularies,
- an appendix giving an example small client vocabulary covering print
and display capabilities, and
- an appendix providing a survey of existing work from which new
vocabularies may be derived.
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. It has now been passed to the W3C Device Independence
Working Group to carry forward towards a Recommendation.
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.
This further Last Call Working Draft is based on the public
interim Working Draft, published on 8 November 2002. It incorporates the
resolution of all last call
issues reported on previous drafts.
As a result of reviewing the criteria that would be set for this
specification to exit Candidate Recommendation, it was decided that the proxy
behavior description had insufficient support for implementation. Proxy
behavior has therefore been removed from this version. This further Last Call
Working Draft has been produced to show the result of this change. In
addition, the RDF primer that was included in this document has been removed
in favor of a reference to the RDF Primer. It
adds an XML schema for the rational datatype proposed by the XML Schema WG. A
two week review period has been set, which will close on 08 April 2003.
At the time of writing, the RDFCore Working
Group is proposing a new mechanism for data typing in RDF, which will
necessitate a change to the structure of CC/PP profiles. This document is
based on the current version of RDF [RDF] which does
not include this new mechanism for data typing.
Further work on aspects of CC/PP other than structure, such as protocol,
processing rules and vocabulary foundations, will continue in the Device Independence Working Group as already defined in
its charter.
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 Device Independence 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. Here profile does not refer to a subset of a particular
specification, for example the CSS Mobile profile, but refers to the
document(s) exchanged between devices that describe the capabilities of a
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. For an introduction to RDF, see [RDFPRIMER]
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.
CC/PP is compatible with IETF media feature sets (CONNEG) [RFC2533] in the sense that all media feature tags and
values can be expressed in CC/PP. However, not all CC/PP profiles can be
expressed as media feature tags and values, and CC/PP does not attempt to
express relationships between attributes.
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 two
main areas:
- CC/PP profile components: support for these is REQUIRED.
- CC/PP profile defaults: support for these is REQUIRED.
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 and use of XML namespaces.
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-schema#"
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-schema#"
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-schema#"
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/hardwareProfile#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/softwareProfile#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/TerminalProfile#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/hardwareProfile#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/softwareProfile#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/terminalProfile#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:memoryMb-------> "32"
[ex:HWDefault]
|
+--rdf:type----> [ex:HardwarePlatform]
+--ex:displayWidth--> "320"
+--ex:displayHeight--> "200"
+--ex:memoryMb---> "16"
|
In this example, the default component indicates 16 Mb of memory, but this
value is overridden by the memoryMb property applied directly to
the profile component. Thus, in this profile, the memoryMb
attribute has a value of 32.
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-schema#"
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:memoryMb>32</ex:memoryMb>
</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:memoryMb>16</ex:memoryMb>
</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.
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-schema#"
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-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.
3. CC/PP structure
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 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.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.
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.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-schema#"
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-schema#"
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.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-schema#"
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.5 Notes on RDF usage
This specification uses "rdf:about" to specify the URIs of
resources. This was a deliberate choice to ensure that such URIs 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
URIs 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 URIs 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.
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.)
All simple CC/PP attribute values are represented as literal text values (in
XML elements or XML attributes, according to the rules for RDF literal object
values).
Base CC/PP usage defined here leaves any further interpretation of the
values used to the processing application. Future versions of CC/PP may
introduce additional structures that provide for standardized matching of
client profiles with other resource metadata. To allow such developments, and
to ease interworking with IETF media feature descriptions, it is RECOMMENDED
that any simple attribute values should be defined in terms of one of the
data types described below.
All attribute values are ultimately sequences of UCS (Unicode) characters.
It is assumed that character coding issues in specific serializations of the
RDF data are defined by the enclosing XML representation.
NOTE: Attribute comparison is beyond the scope of this
document, as are specific mechanisms for determining the simple type
corresponding to a given attribute value. Applications are presumed to know
how to deal with any CC/PP attribute that they handle.
Where given, formal syntax expressions use the notation presented in
Section 6 of the XML specification [XML].
A common requirement is to identify some resource using a URI as the value
of a CC/PP attribute (e.g. a device type or an applicable DTD or schema).
In such cases, the attribute value is represented as an RDF resource
having the designated URI. In RDF/XML, this may be represented as an
<rdf:Description> element in a property element, or
an rdf:resource XML attribute of a property element;
e.g.
Figure 4-1: Attribute URI values
URI attribute value
using <rdf:Description>
element:
<ex:property>
<rdf:Description rdf:about="http://example.com/profileURI" />
</ex:property>
URI attribute value
using rdf:resource
attribute:
<ex:property rdf:resource="http://example.com/schemaURI"/>
|
RFC 2396 [RFC2396], section 2.1, discusses the use
of non-ASCII characters in URIs, and notes in particular that a URI may be
represented as an original character sequence or as a URI
character sequence. The representation of URI values in CC/PP
attributes should be as an original character sequence, subject
to whatever character coding scheme is used by the containing XML document
(usually UTF-8 or UTF-16). When the URI is required in the form of a
URI character sequence (e.g. for retrieving a resource
referenced by the URI), the transformation described by XML [XML] (second edition, section 4.2.2 and erratum 26) for
system identifiers should be applied.
A text value is a string that is used to describe or identify some specific
CC/PP attribute value.
Text values are based on the "string" XML schema datatype [XMLSCHEMA-2].
In general, such values may be compared for equality or inequality.
Depending on the application and context, such comparison may be compared in
different ways, as indicated below. In the absence of specific knowledge to
the contrary, exact matching (case sensitive) should be assumed.
When comparing case sensitive text, every character must match exactly for
equality to be declared.
Some examples:
- Browser name: "Mozilla"
- Browser version: "5.0"
Tokens are case sensitive text values using a constrained subset of US-ASCII
characters, generally used to name an enumerated set of values. All character
values must match exactly.
The exact constraints on the characters allowed in a token value may vary
from application to application; e.g. IETF media feature values that are
tokens may use upper- and lowercase letters, digits and hyphens [RFC2533]; IETF charset names [RFC2278] are defined to allow any US-ASCII character
other than control characters (0-31), space (32) double quote (34) and
specified special characters: "(", ")", "<", ">", "@", ",", ";",
":", "/", "[", "]", "?", ".", "=" and "*".
Some examples:
- Charset name: "US-ASCII", "UTF-8", "I-Default"
- Language name: "en", "en-us", "fr"
Integer numbers may be positive, zero or negative. They are represented by
a string containing a sequence of decimal digits, optionally preceded by a
'+' or '-' sign. Leading zeros are permitted and are
ignored. The number value is always interpreted as decimal (radix 10). It is
RECOMMENDED that implementations generate and support integer values in the
range -2147483648 to +2147483647, or -(2^31) to (2^31-1); i.e. integers whose
absolute value can be expressed as a 31-bit unsigned binary number.
Figure 4-2: Syntax for integer numbers
Signed-integer ::= ( '+' | '-' )? Unsigned-integer
Unsigned-integer ::= Digit (Digit)*
|
Integer values are based on the "int" XML schema datatype [XMLSCHEMA-2].
Some examples:
A rational number is expressed as a ratio of two integer numbers. Two
positive integers are separated by a '/', and optionally preceded by
a '+' or '-' sign.
It is RECOMMENDED that implementations generate and support numerators of
a rational number (the first number, before the '/') in the range 0
to 2147483647 (2^31-1), and denominators (after the '/') in the
range 1 to 2147483647.
Figure 4-3: Syntax for rational numbers
Rational-number ::= Signed-integer ( '/' Unsigned-integer )?
|
If the denominator is omitted, a value '1' is assumed; i.e. treat
value as an Integer.
Some examples:
- 1/2 -- this is equivalent to decimal 0.5
- 768/1024
- -254/100
- +2000/65536
NOTE: The rational number schema described above may be
defined in XML-Schema [XMLSCHEMA-0] as follows:
Figure 4-4: Possible XML-Schema for rational
numbers
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030320/">
<xs:simpleType name="rational">
<xs:annotation>
<xs:documentation>
The canonical lexical representation of any value
will be the form of the value reduced to its lowest
common denominator, and with '1' in the denominator
if applicable.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]+(/[0-9]+)?"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
|
The above definition only solves one half of the problem, i.e. it
describes only the lexical representation. Binding a lexical representation
to a value space is not easy; it requires operator definition, and must be
carefully described since processors which understand simple types will be
expected to do the arithmetic. Until the XML-Schema Working Group has
defined a rational number datatype with operators, the use of rational
numbers may be harmful to interoperability.
4.1.2 Complex CC/PP attribute data
In addition to the simple values described above, a CC/PP attribute may have
a complex value expressed in the form of a resource with its own collection
of RDF properties and associated values. Specific data types represented in
this way are:
- Set of values
- Sequence of values
Other complex CC/PP attribute values may be represented by arbitrary RDF
resources. A definition of the interpretation of such values is beyond the
scope of this specification.
A set consists of zero, one or more values, all different and whose order is
not significant.
Set values are useful for representing certain types of device
characteristics; e.g. the range of typefaces that can be supported by a
client, or the HTML versions supported by a browser.
A set is represented as an 'rdf:Bag', with each member of
the set corresponding to a property of that resource named
'rdf:_1', 'rdf:_2', etc. This construct is
described in section 3 of the RDF Model and Syntax specification [RDF].
Figure 4-4: RDF representation of set values in
CC/PP
[(Client-resource)]
+--(attributeName)--> [<rdf:Bag>]
+--rdf:_1--> (set-member-value-1)
+--rdf:_2--> (set-member-value-2)
:
+--rdf:_n--> (set-member-value-n)
|
NOTE: The 'rdf:Bag' construct
does not require that every contained value be unique. A set cannot contain
duplicate values, so every property of an 'rdf:Bag' used to
represent a set must have a distinct value.
There is a clear distinction drawn between an attribute that has a single
value, and an attribute whose value is a set with zero, one or more
elements:
Figure 4-5: Attribute with set value containing a
single member
[(Client-resource)]
+--(attributeName)--> [<rdf:Bag>] --rdf:_1--> (set-member-value)
|
Compare the above attribute value, which is a set containing one element,
with the following, which is a simple value:
Figure 4-6: Attribute with a simple value
[(Client-resource)]
+--(attributeName)--> (attribute-value)
|
A sequence consists of zero, one or more values, whose order is significant
in some way.
Sequence values are useful for a range of client features that may be
ordered or ranked in some way; e.g. a list of preferences in some order of
preference. This specification does not define the significance of the
ordering of values. A vocabulary that defines a sequence-valued CC/PP
attribute should also define the significance of the ordering of within the
sequence.
A sequence is represented as an 'rdf:Seq', with each
member of the set corresponding to a property of that resource named
'rdf:_1', 'rdf:_2', etc. This construct is
described in section 3 of the RDF Model and Syntax specification [RDF].
Figure 4-7: RDF representation of sequence values
in CC/PP
[(Client-resource)]
+--(attributeName)--> [<rdf:Seq>]
+--rdf:_1--> (sequence-value-1)
+--rdf:_2--> (sequence-value-2)
:
+--rdf:_n--> (sequence-value-n)
|
There is a clear distinction drawn between an attribute that has a single
value, and an attribute whose value is a sequence with zero, one or more
elements:
Figure 4-8: Attribute with sequence value
containing a single member
[(Client-resource)]
+--(attributeName)--> [<rdf:Seq>] --rdf:_1--> (sequence-value)
|
Compare the above attribute value, which is a sequence containing one
element, with the simple value as shown in figure 4-5 above.
CC/PP attribute names are in the form of a URI. Any CC/PP vocabulary is
associated with an XML namespace, which combines a base URI with a local XML
element name (or XML attribute name) to yield a URI corresponding to an
attribute name. E.g. the namespace URI:
http://www.w3.org/2002/11/08-ccpp-client#
and the core vocabulary name:
type
are combined to yield the attribute name URI:
http://www.w3.org/2002/11/08-ccpp-client#type
Anyone can define and publish a CC/PP vocabulary extension (assuming
administrative control or allocation of a URI for an XML namespace). For such
a vocabulary to be useful, it must be interpreted in the same way by
communicating entities. Thus, use of an existing extension vocabulary is
encouraged wherever possible; failing this, publication of a new vocabulary
definition containing detailed descriptions of the new CC/PP attributes.
Many extension vocabularies will be drawn from existing applications and
protocols; e.g. WAP UAProf, IETF media feature registrations, etc. Appendix E surveys some possible sources of additional
CC/PP vocabularies.
Attribute names are defined, and associated with an XML namespace, using
an RDF schema.
Appendix B to this document contains an RDF schema with which all CC/PP
profiles must conform, and Appendix C contains an example of a vocabulary
definition schema. Appendix D contains recommendations for creating a new
vocabulary.
A CC/PP processor is not required to understand and process RDF Schema
definitions; it merely needs to understand enough about the CC/PP profile
structure and vocabulary used to perform its job. (A schema-aware processor
may be able to handle CC/PP profiles in other ways, or in combination with
other RDF information, but such behavior is beyond the scope of this
specification.)
5. Acknowledgments
This document is a distillation of many discussions of the W3C CC/PP
Working Group. The following were Working Group members for some or all of
the period of preparation of this specification, and its predecessors:
- Mikael Nilsson, Ericsson Infotech, Mikael.Nilsson@ks.ericsson.se
- Ulrich Kauschke, T-Mobil, Ulrich.Kauschke@t-mobil.de
- Ann Navarro, HTML Writers Guild, ann@hwg.org
- Brad Topol, IBM, btopol@us.ibm.com
- Franklin Reynolds, Nokia, franklin.reynolds@nokia.com
- Graham Klyne, Baltimore Technologies, graham.klyne@mimesweeper.com
- Noboru Iwayama, Fujitsu Laboratories LTD,
iwayama.noboru@jp.fujitsu.com
- Takashi Nishigaya, Fujitsu Laboratories LTD,
takashi@flab.fujitsu.co.jp
- Lalitha Surayanrayana, SBC Technology Resources,
lalitha@tri.sbc.com
- Hidetaka Ohto, W3C/Panasonic, ohto@w3.org
- Simon McBride, DSTC Pty Ltd, sjm@dstc.edu.au
- Varuni Witana, DSTC Pty Ltd, varuni@dstc.uts.edu.au
- Chris Woodrow, Information Architects, woodroc@metaphoria.net
- Johan Hjelm, Ericsson, johan.hjelm@era-t.ericsson.se
- Barry Briggs, Interleaf, bbriggs@interleaf.com
- Gerd Hoelzing, SAP, gerd.hoelzing@sap.com
- Ted Hardie, Equinix, hardie@equinix.com
- Serge Rigori, Sun, serge.rigori@france.sun.com
- Ted Wugofski, Phone.com, ted.wugofski@corp.phone.com
- Kynn Bartlett, HTML Writers Guild, kynn@idyllmtn.com
- Sandeep Singhal, IBM
- Thorsten Kassing, T-Mobil
- Larry Masinter, Adobe
Useful revisions and clarifications were suggested by Yuichi Koike, Stuart
Williams, Sean Palmer and Toni Penttinen. Special thanks are due to Aaron
Swartz for a very thorough and revealing review of the last call draft.
6.1. Normative References
- [XML]
- Extensible Markup Language (XML) 1.0 (Second Edition); Tim Bray, Jean
Paoli, C. M. Sperberg-McQueen, Eve Maler; World Wide Web Consortium
Recommendation: http://www.w3.org/TR/REC-xml
As amended by: XML 1.0 Second Edition Specification Errata; http://www.w3.org/XML/xml-V10-2e-errata,
specifically http://www.w3.org/XML/xml-V10-2e-errata#E26.
- [XMLNAMESPACES]
- Namespaces in XML; Tim Bray, Dave Hollander, Andrew Layman; World
Wide Web Consortium Recommendation: http://www.w3.org/TR/REC-xml-names
- [RDF]
- Resource Description Framework (RDF) Model and Syntax Specification;
Ora Lassila, Ralph Swick; World Wide Web Consortium Recommendation: http://www.w3.org/TR/REC-rdf-syntax
- [RDFSCHEMA]
- Resource Description Framework (RDF) Schema Specification; Dan
Brickley, R. V. Guha; World Wide Web Consortium Candidate
Recommendation 27 March 2000: http://www.w3.org/TR/2000/CR-rdf-schema-20000327/
- [RDFXML]
- RDF/XML Syntax Specification; Dave Beckett; World Wide Web Consortium
Working Draft: http://www.w3.org/TR/rdf-syntax-grammar/
6.2. Informative References
- [RFC2506]
- RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A.
Mutz, T. Hardie; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2506.txt
- [RFC2533]
- RFC 2533: A Syntax for Describing Media Feature Sets; G. Klyne; IETF
Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2533.txt
- [CONNEGMATCH]
- A revised media feature set matching algorithm; G. Klyne;
Internet-Draft, work in progress:
<draft-klyne-conneg-feature-match-02.txt>
- [RFC2534]
- RFC 2534: Media Features for Display, Print, and Fax; L. Masinter, D.
Wing, A. Mutz, K. Holtman; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2534.txt
- [UAPROF]
- WAP-174: WAG UAProf User Agent Profile Specification; Wireless
Application Group;
http://www1.wapforum.org/tech/terms.asp?doc=SPEC-UAProf-19991110.pdf
As amended by WAP Specification Information Note WAP-174_100-UAProf
Version 21-Jun-2000
http://www1.wapforum.org/tech/documents/WAP-174_100-UAProf-20000621-a.pdf
Also see WAP Specification Information Note WAP-248-UAProf Version
20-Oct-2001:
http://www1.wapforum.org/tech/documents/WAP-248-UAProf-20011020-a.pdf
- [DATASTRUCTURE]
- Notes on Data Structuring; C. A. R. Hoare; in Structured Programming,
Academic Press, 1972. ISBN 0-12-2000556-2.
- [XMLSCHEMA-0]
- XML Schema. Part 0: Primer; David C. Fallside; W3C Proposed
Recommendation: http://www.w3.org/TR/xmlschema-0/
- [XMLSCHEMA-1]
- XML Schema. Part 1: Structures; Henry S. Thompson, David Beech,
Murray Maloney, Noah Mendelsohn; W3C Proposed Recommendation: http://www.w3.org/TR/xmlschema-1/
- [XMLSCHEMA-2]
- XML Schema. Part 2: Datatypes; Paul V. Biron, Ashok Malhotra; W3C
Proposed Recommendation: http://www.w3.org/TR/xmlschema-2/
- [SEMANTICTOOLBOX]
- The Semantic Toolbox: Building Semantics on top of XML-RDF; Tim
Berners-Lee; http://www.w3.org/DesignIssues/Toolbox.html
- [RFC2531]
- RFC 2531: Content Feature Schema for Internet Fax; G. Klyne, L.
McIntyre; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2531.txt
- [TIFF]
- TIFF (Tagged Image File Format) 6.0 Specification; Adobe Systems
Inc.; http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
- [RFC2301]
- RFC 2301: File Format for Internet Fax; L. McIntyre, S. Zilles, R.
Buckley, D. Venable, G. Parsons, J. Rafferty; IETF Request for
Comments: ftp://ftp.isi.edu/in-notes/rfc2301.txt
- [MULTIMEDIA]
- Multimedia Programming Interface and Data Specifications 1.0
(contains WAVE file format); IBM Corporation and Microsoft Corporation;
<riffspec.txt>
- [RFC2361]
- RFC 2361: WAVE and AVI Codec Registries; E. Fleischman; IETF Request
for Comments: ftp://ftp.isi.edu/in-notes/rfc2361.txt
- [MPEG]
- MPEG-4 Overview - (V.14 - Geneva Version), ISO/IEC JTC1/SC29/WG11
N3444 Rob Koenen Overview of the MPEG-4 Standard:
- [PWG]
- Printer Working Group; http://www.pwg.org
- [RFC2566]
- RFC 2566: Internet Printing Protocol/1.0: Model and Semantics; R.
deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell; IETF Request
for Comments: ftp://ftp.isi.edu/in-notes/rfc2566.txt
- [SALUTATION]
- Salutation Consortium Specification; http://www.salutation.org/
- [RFC2119]
- RFC 2119: Key words for use in RFCs to Indicate Requirement Levels;
S. Bradner; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2119.txt.
- [MPEG-7]
- MPEG-7 Overview (version 8.0), ISO/IEC JTC1/SC29/WG11 N3445 José M.
Martínez (UPM-GTI, ES) Overview of the MPEG-7 Standard: http://mpeg.telecomitalialab.com/standards/mpeg-7/mpeg-7.htm
- [RFC2277]
- RFC 2277: IETF Policy on Character Sets and Languages; H. Alvestrand;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2277.txt
- [RFC2396]
- RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax; T.
Berners-Lee, R. Fielding, L. Masinter; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2396.txt
- [RFC2278]
- RFC 2278: IANA Charset Registration Procedures; N. Freed, J. Postel;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2278.txt
- [CCPPARCH]
- Composite Capabilities/Preference Profiles: Requirements and
Architecture; Mikael Nilsson, Johan Hjelm, Hidetaka Ohto; W3C Working
Draft: http://www.w3.org/TR/CCPP-ra/
- [RFC2616]
- RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1; R. Fielding, J.
Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2616.txt
- [CONCEPTUAL]
- Conceptual Structures: Information Processing in Mind and Machine;
John F. Sowa; Addison Wesley, Reading MA, 1984.
- [KNOWLEDGE]
- Knowledge Representation; John F. Sowa; Brooks/Cole, 2000. ISBN:
0-534-94965-7
- [RDFFRAGMENT]
- Re: How to address RDF fragment; Ralph R Swick; Message to W3C
RDF-comments mailing list:
http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html.
- [CCPPEX]
- CC/PP exchange protocol;Hidetaka Ohto, Johan Hjelm;World Wide Web
Consortium Note: http://www.w3.org/TR/NOTE-CCPPexchange
- [WAI]
- Web Content Accessibility Guidelines 2.0; Wendy Chisholm, Jason
White, Gregg Vanderheiden; World Wide Web Consortium Working Draft: http://www.w3.org/TR/WCAG20/
- [RDFPRIMER]
- RDF Primer; Frank Manola, Eric Miller; World Wide Web Consortium
Working Draft: 23 January 2003 http://www.w3.org/TR/rdf-primer/
A. Terminology and abbreviations
A.1 Terminology
This appendix is INFORMATIVE.
- Attribute, or CC/PP attribute
- A CC/PP attribute refers to the data elements describing the profile
and is denoted as an RDF property. Each CC/PP attribute is associated
with a value or a list of values or am RDF resource.
NOTE: this is quite distinct from an XML attribute;
except where the meaning obvious in context, the term "CC/PP attribute"
is generally used to emphasize this usage.
- CC/PP Processor
- A CC/PP processor transforms a CC/PP document from its RDF format
into some other format. A CC/PP processor understands CC/PP syntax and
structure, including "defaults", but it does not understand application
semantics associated with CC/PP attributes of CC/PP components.
- CC/PP Repository
- A server that stores the user agent profile or profile segments
persistently in a form that may be referenced by and incorporated into
a profile. A CC/PP repository is typically a Web server that provides
CC/PP profiles or profile segments in response to HTTP requests.
- Cacheable
- A data resource is said to be "cacheable" if the data resource
contains a property that allows a server to determine whether the
cached resource matches a request for a similar resource.
- Cache
- A storage area used by a server or proxy to store data resources that
have been retrieved or created in response to a request. When a new
request for a "cached" data resource is received, the server or proxy
can respond with the cached version instead of retrieving or creating a
new copy.
- Capability
- An attribute of a sender or receiver (often the receiver) which
indicates an ability to generate or process a particular type of
message content. See also "CC/PP Attributes".
- Client
- An entity that is the original compositor of a CC/PP profile.
- Confidentiality
- Protecting the content of a message from unauthorized disclosure.
- Content Generation
- For the purpose of this specification, "content generation" refers to
generating content appropriate to the user agent profile of the request
by using the user agent profile as input to a dynamic content
generation engine. The XSL and style sheets of the document are used to
tailor the document to the user agent profile of the request.
- Content Negotiation
- The mechanism for selecting the appropriate representation when
servicing a request. The representation of entities in any response can
be negotiated (including error responses).
- Content Selection
- For the purpose of this specification, "content selection" refers to
selecting an appropriate document from a list of possible choices or
variants by matching the document profile with the user agent profile
of the request.
- Content Provider
- A server that originates content in response to a request.
- Data Resource
- A data object that can be transferred across a network. Data
resources may be available in multiple representations (e.g. multiple
languages, data formats, size, resolutions) or vary in other ways.
- Document
- For the purpose of this specification, "document" refers to content
supplied in response to a request. Using this definition, a "document"
may be a collection of smaller "documents", which in turn is a part of
a greater "document".
- Document Profile
- Document profiles offer a means to characterize the features
appropriate to given categories of user agents. For instance, one
profile might include support for style sheets, vector graphics and
scripting, while another might be restricted to the tags in HTML 3.2.
Document profiles can be used by servers to select between document
variants developed for different user agent categories. They can be
used to determine what transformations to apply when such variants are
not available. Content developers can use document profiles to ensure
that their Web sites will be rendered as intended.
- Dynamic Content
- Content that is generated in response to a request. This may be used
for content that depends on changing environmental factors such as time
(e.g., stock quotes) or place (e.g., nearby gas stations)
- Feature
- Functional property of a device or entity.
- Gateway
- Software that is capable of bridging disparate network protocols. For
the purposes of this specification, "gateway" refers to protocol
bridging functionality, which may exist in a stand-alone gateway or may
be co-located with a proxy or origin server.
- Hint
- A suggestion or preference for a particular option. While this option
is strongly recommended, its use is not required.
- Machine Understandable
- Data that is described with tags that associate a meaning to the data
(i.e., an "author" tag would describe the author of the document),
allowing data to be searched or combined and not just displayed.
- Namespace
- A qualifier added to an XML tag to ensure uniqueness among XML
elements.
- Negotiate Content
- Message content that has been selected by content negotiation.
- Negotiation Metadata
- Information which is exchanged between the sender and the receiver of
a message by content negotiation in order to determine the variant
which should be transferred.
- Non-variant Content
- When the form/format of the content being sent does not depend on
receiver's capabilities and/or preferences
- Origin Server
- Software that can respond to requests by delivering appropriate
content or error messages. The origin server may receive requests via
either WSP or HTTP. Application programs executing on the origin server
deliver content that is tailored in accordance with the CC/PP that can
be found within the provided Profile. For the purpose of this
specification, "origin server" refers to content generation
capabilities, which may physically exist in a stand-alone Web server or
may be co-located with a proxy or gateway.
- Preference
- An attribute of a sender or receiver (often the receiver) which
indicates a preference to generate or process one particular type of
message content over another, even if both are possible.
- Privacy
- Preventing the unintended or unauthorized disclosure of information
about a person. Such information may be contained within a message, but
may also be inferred from patterns of communication; e.g. when
communications happen, the types of resource accessed, the parties with
whom communication occurs, etc.
- Profile
- An instance of the schema that describe capabilities for a specific
device and network. A profile need not have all the attributes
identified in the vocabulary/schema.
- Proxy
- Software that receives HTTP requests and forwards that request toward
the origin server (possibly by way of an upstream proxy) using HTTP.
The proxy receives the response from the origin server and forwards it
to the requesting client. In providing its forwarding functions, the
proxy may modify either the request or response or provide other
value-added functions. For the purposes of this specification, "proxy"
refers to request/response forwarding functionality, which may exist in
a stand-alone HTTP proxy or may be co-located with a gateway or origin
server.
- RDF Resource
- An object or element being described by RDF expressions is a
resource. An RDF resource is typically identified by a URI.
- Receiver
- A system component (device or program) which receives a message.
- Schema, RDF Schema
- An RDF Schema denotes resources which constitute the particular
unchanging versions of an RDF vocabulary at any point in time. It is
used to provide information (such as organization and relationship)
about the interpretation of the statements in an RDF data model. It
does not include the values associated with the attributes.
- Security
- Describes a set of procedures applied to data communications to
ensure that information is transferred exactly as the sender and
receiver intend, and in no other way. Security generally breaks down
into Integrity, Authentication, Confidentiality and Privacy.
- Sender
- A system component (device or program) which transmits a message.
- User
- An individual or group of individuals acting as a single entity. The
user is further qualified as an entity who uses a device to request
content and/or resource from a server.
- User agent
- A program, such as a browser, running on the device that acts on a
user's behalf. Users may use different user agents at different
times.
- User agent profile
- Capabilities and preference information pertaining to the
capabilities of the device, the operating and network environment, and
users personal preferences for receiving content and/or resource.
- Variant
- One of several possible representations of a data resource.
- Variant Content
- When the form/format of the content being sent depends on receiver's
capabilities and/or preferences
- Vocabulary
- A collection of attributes that adequately describe the CC/PP. A
vocabulary is associated with a schema.
| CC/PP |
Composite Capabilities/Preferences Profile |
| CC/PPex |
CC/PP Exchange Protocol |
| CONNEG |
Content Negotiation Working Group in the IETF |
| ER |
Entity-Relationship |
| HTML |
HyperText Markup Language |
| HTTP |
HyperText Transfer Protocol |
| HTTPex |
HTTP Extension Framework |
| IANA |
Internet Assigned Numbers Authority |
| IETF |
Internet Engineering Task Force |
| IOTP |
Internet Open Trading Protocol |
| LDAP |
Lightweight Directory Access Protocol |
| OTA |
Over The Air, i.e. in the radio network |
| RDF |
Resource Description Framework |
| RFC |
Request For Comments |
| TBD |
To Be Determined |
| TCP/IP |
Transmission Control Protocol/Internet Protocol |
| UAProf |
WAP User Agent Profile |
| W3C |
World Wide Web Consortium |
| WAP |
Wireless Application Protocol |
| WBXML |
WAP Binary XML |
| WML |
Wireless Markup Language |
| WSP |
Wireless Session Protocol |
| XHTML |
Extensible HyperText Markup Language |
| XSL |
Extensible Stylesheet Language |
| XML |
Extensible Markup Language |
B. RDF schema for structure
This appendix is NORMATIVE, but support by CC/PP processors is
OPTIONAL.
Figure B-1: CC/PP class hierarchy
rdfs:Resource
ccpp:Profile {Profile deliverable to origin server}
ccpp:Component
rdfs:Literal
ccpp:anyURI {A URI-string value of a CC/PP attribute}
ccpp:string {A text value of a CC/PP attribute}
ccpp:integer {An integer value of a CC/PP attribute}
ccpp:Rational {A rational number CC/PP attribute value}
rdf:Bag {A set value for a CC/PP attribute}
rdf:Seq {A sequence value for a CC/PP attribute}
rdf:Property
ccpp:Property {A property applied to a CCPP:Resource}
ccpp:Structure {A structural property in a CC/PP profile}
ccpp:Attribute {A property denoting a CC/PP attribute}
|
Figure B-3: CC/PP structural properties
ccpp:component Domain=ccpp:Client-profile, Range=ccpp:Component
ccpp:defaults Domain=ccpp:Component, Range=ccpp:Component
|
(Schema URI: http://www.w3.org/2002/11/08-ccpp-schema)
Figure B-3: RDF schema for CC/PP classes and core
properties
<?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-schema#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'>
<!-- CC/PP class definitions -->
<rdfs:Class rdf:about='&ns-ccpp;Profile'>
<rdfs:label xml:lang="en">CC/PP Profile</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
<rdfs:comment xml:lang="en">
This class is any complete profile that can be delivered to an
origin server or other system that generates content for a client.
May be a Request-profile or a Client-profile.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;Component'>
<rdfs:label xml:lang="en">CC/PP profile component</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
<rdfs:comment xml:lang="en">
A base class for any collection of CC/PP attribute values.
A CC/PP client profile consists of one or more components,
typically using a derived class that indicates the use of the
component (e.g. prf:HardwarePlatform, prf:SoftwarePlatform).
This class is also used for collecting CC/PP attributes that
form part of a proxy behavior description.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;anyURI'>
<rdfs:label xml:lang="en">URI value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class defines the CC/PP anyURI data type.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#anyURI'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;string'>
<rdfs:label xml:lang="en">Text value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class defines the CC/PP string data type.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#string'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;integer'>
<rdfs:label xml:lang="en">Integer value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class defines the CC/PP integer data type.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#integer'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;Rational'>
<rdfs:label xml:lang="en">Rational value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class is used to represent any CC/PP attribute value that is
a rational number.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;Property'>
<rdfs:label xml:lang="en">CC/PP Property</rdfs:label>
<rdfs:subClassOf rdf:resource=' |