Composite Capability/Preference Profiles (CC/PP): Structure and
Vocabularies 1.0
W3C Recommendation 15 January 2004
- This version:
- http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/
- Latest version:
- http://www.w3.org/TR/CCPP-struct-vocab/
- Previous version:
- http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/
- 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
(through March 2002) / 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
Please refer to the errata for this
document, which may include some normative corrections.
The English version of this specification is the only normative version.
Non-normative translations may
also be available.
Copyright © 2004
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. This is often referred to as a device's
delivery context and 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 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. A list of current
W3C publications and the latest revision of this technical report can be
found in the W3C technical reports index
at http://www.w3.org/TR/.
This document is a Recommendation of the W3C. It has been reviewed by W3C
Members and other interested parties, and has been endorsed by the Director
as a W3C Recommendation. It is a stable document and may be used as reference
material or cited as a normative reference from another document.
W3C's role in making the Recommendation is to draw attention to the
specification and to promote its widespread deployment. This enhances the
functionality and interoperability of the Web. A test
suite for has been developed, along with an implementation
report.
This document has been produced by the W3C Device Independence Working
Group as part of the Device Independence
Activity within the W3C
Interaction Domain. Continued status of the work is reported on the Device Independence Working Group Home Page (Member-only link).
The public is invited to send comments or reports errors to the editors at
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/.
Patent disclosures relevant to this specification may be found on the
CC/PP Working Group's patent
disclosure page in conformance with W3C policy.
Table of contents
1. Introduction
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. 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]. Note that the [RDFPRIMER] document describes a more recent revision
of the RDF specifications than the ones on which this specification is
based.
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 to
describe its 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, we have
attempted to accomodate existing UAProf profiles.
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 Structure and Vocabularies (abbreviated to CC/PP in the rest of this
document) defines 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
(see section 5). 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. It is not 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 are instances of
ccpp:Attribute, new component classes are subclasses of
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)
to 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.
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
This section is not normative, but provides an overview of the features of
CC/PP.
2.1 CC/PP profile structure
A CC/PP profile is broadly constructed as a 2-level hierarchy:
- a profile having at least one or more 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:MyProfile]
|
+--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.2"
+--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.2</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 profile 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:defaults 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.2"
+--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/schema#SoftwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/softwareProfile#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.2</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/hardwareProfile#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/hardwareProfile#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.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.
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 MUST 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-schema#
Normative RDF schema defining class declarations for CC/PP, and core
structural properties (listed in Appendix
B.3).
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
(listed in Appendix C).
NOTE: To retrieve these schemas it is necessary for your
browser to add the header Accept:text/xml in the request.
Browsers 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 one or more components, and each
component contains one or more attributes. Each component is represented by a
resource of type ccpp:Component (or some RDFS subclass
thereof), and related to the client profile resource by a
ccpp:component property. Here, the
ccpp namespace is
http://www.w3.org/2002/11/08-ccpp-schema#. For compatibility with UAProf, the
namespace used to qualify component MAY be a UAProf
namespace.
The object of 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 figure
2-2b 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 RDF
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 MUST 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 RDF literal 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 single 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. Here, the ccpp namespace is
http://www.w3.org/2002/11/08-ccpp-schema#. For compatibility with UAProf, the
namespace used to qualify defaults or Defaults MAY
be a UAProf namespace.
Defaults can be encoded inline or as separate documents referred to via
URI. Defaults can not be encoded both inline and as a separate document. 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--> { "2.0", "3.2", "4.0" }
[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.2", "4.0" }
|
If a component referenced by ccpp:defaults 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--> { "2.0", "3.2", "4.0" }
+--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.2</rdf:li>
<rdf:li>4.0</rdf:li>
</rdf:Bag>
</prf:htmlVersionsSupported>
</rdf:Description>
</ccpp:defaults>
<prf:htmlVersionsSupported>
<rdf:Bag>
<rdf:li>2.0</rdf:li>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</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>2.0</rdf:li>
<rdf:li>3.2</rdf:li>
<rdf:li>4.0</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.2</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 properties that are
not defined in the CC/PP or RDF namespaces:
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.2</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 in examples. This was a deliberate choice to ensure that such URIs
are absolutely and unambiguously specified. This is also 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 [RDFFRAGMENT]. 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, 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.
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 RDF plain literal
values. In RDF/XML these may appear as character sequences either in XML
elements or as XML attributes.
The acceptable plain literal values for an attribute may be constrained to
the lexical space associated with a specific application data type. This
section introduces some specific data types that may be associated with
simple CC/PP attributes.
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].
The data type of a CC/PP attribute value may be defined to be a case
sensitive text string.
The RDF literal value is constrained to the lexical space defined in the
"string" XML schema datatype [XMLSCHEMA-2]. Any 'lang' tag
is ignored.
In general, such values may be compared for equality or inequality. When
comparing text values, every character must match exactly for equality to be
declared.
Some examples:
- Browser name: "Mozilla"
- Browser version: "5.0"
The data type of a CC/PP attribute value may be defined to be an integer
number.
The RDF literal value is constrained to the lexical space defined in the
"int" XML schema datatype [XMLSCHEMA-2]. Any 'lang' tag is
ignored.
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)*
|
Some examples:
The data type of a CC/PP attribute value may be defined to be a rational
number.
In other words, the RDF literal value is constrained to the lexical space
defined below. Any 'lang' tag is ignored.
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
- 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-20030728/">
<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*[1-9][0-9]*)?"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
|
Note that while the pattern above provides a lexical definition, it does
so imperfectly: it strictly disallows any whitespace at all. Further, the
simple type definition above does not define a numeric value space;
ordering, equality, and implied support for arithmetic operations are not
defined as some users of the type might expect -- processors need only
recognize the definition as a string. Because of these deficiencies, use of
rational numbers as defined here may be harmful to interoperability. (The
XML-Schema Working Group may define a workable rational data type in the
future.)
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
A profile MUST NOT have multiple occurrences of a single attribute within
a single component. CC/PP attributes that need to have multiple values should
use sets or sequences. 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-6 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 reference:
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 describing terms for use in CC/PP profiles. Appendix C contains an example Schema describing a
CC/PP vocabulary. 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. Conformance
This section explains how to make a valid
claim that a product conforms to this specification. Anyone may make a
claim (e.g., vendors about their own products, third parties about those
products, journalists about products, etc.). Claims may be published anywhere
(e.g., on the Web or in product documentation). Claimants are solely
responsible for their claims. If the subject of the claim (e.g., the
software) changes after the date of the claim, the claimant is responsible
for updating the claim. Claimants are expected to modify or retract a claim
if it may be demonstrated that the claim is not valid. Claimants are
encouraged to conform to the most recent specification available.
There are three classes of products of CC/PP:
- documents (e.g. a web resource)
- producers (e.g. a web client)
- consumers (e.g. a web server)
5.1 CC/PP Document Conformance
Documents may exist as resources accessible via a URL, or may be
transmitted as data in a message. A document is CC/PP conformant when it
meets the following criteria:
- The document MUST be valid RDF serialized
in XML, and be based on one or more vocabularies derived from the RDF
Schema in Appendix B. See section 1.
- The document MUST use valid syntax for namespace declarations. See section 2.2.
- The profile element MUST contain one or more components. See section 2.1.
- Each component in the profile MUST contain one or more attributes. See
section 2.1.
- The component names MAY be in rdf:about or rdf:ID attributes. See section 3.1.
- Components MUST be indicated using a ccpp:component property where the
namespace used to qualify component is the CC/PP namespace or a UAProf
namespace. See section 3.1.
- Component names, component types, and attribute names must all refer to
different URIs within a profile. See section
3.
- If a component type is given as an element name and as an rdf:type
element, they MUST refer to the same URI. See section 3.1.
- Default references MUST be valid URLs. See section 3.3.
- Defaults MAY be written as ccpp:defaults or ccpp:Defaults. See section 3.3.
- Defaults MUST be indicated using a ccpp:defaults or ccpp:Defaults
property where the namespace used to qualify defaults or Defaults is the
CC/PP namespace or a UAProf namespace. See section 3.3.
- Component attributes MAY contain both a default value and a directly
applied value, with the directly applied value taking precedence. See section 3.3.
- Components MAY contain inline defaults. See section 3.3.
- Components MUST NOT contain both inline and referenced defaults. See section 3.3.
- Components MAY reference a default document which does not have an
rdf:type. See section 3.3.
- Attributes MAY have sets of values (Bags). See section 4.1.2.1.
- Attributes MAY have sequences of values (Seq). See section 4.1.2.2.
- Attributes MAY have string values. See section 4.1.1.2.
- Attributes MAY have Integer number values. See section 4.1.1.3.
- Attributes MAY have Rational number values. See section 4.1.1.4.
- A component MUST NOT contain more than one attribute with the same
name. See section 3.2.
- Attributes of the same name MAY be in different components. See section 3.1.
- Profiles MAY use multiple namespaces for attributes. See section 2.2.
5.2 CC/PP Producer Conformance
A producer is CC/PP conformant when any CC/PP profile document generated
by the producer is a CC/PP conformant document.
5.3 CC/PP Consumer Conformance
A consumer is CC/PP conformant when the consumer accepts any CC/PP
conformant document and extracts CC/PP information. Schema-aware processing
is not required, and therefore, support for the RDF Schema in Appendix B by CC/PP consumers is OPTIONAL (see section 4.3).
There are two categories of conformance for CC/PP consumers:
- Conformant: a CC/PP consumer can claim to be a "CC/PP 1.0
conformant consumer" if it accepts any valid CC/PP profile and
extracts information from it.
- Validating: a CC/PP consumer can claim to be a "CC/PP 1.0
conformant validating consumer" if it is conformant and if it rejects
all invalid CC/PP profiles.
NOTE: A
consumer implementation may be configurable to act as either a conformant
consumer or a conformant validating consumer at different times.
5.4 Conformance Claims
5.4.1 Validity
A conformance claim is valid if it is well formed and meets the appropriate
conformance criteria for the applicable product class as given above.
5.4.2 Well-formed
A conformance claim is well-formed if it includes the following
information:
- the date of the claim
- the product class (document, producer, or consumer)
- the consumer category (conformant or conformant validating) if
applicable
- the title and dated URI of this document
- the product name (identity), including a version, date, or other
identifier that uniquely identifies the product
6. Acknowledgments
This document is a distillation of many discussions of the W3C CC/PP
Working Group, with final amendments introduced by the W3C Device
Independence Working Group. The following were CC/PP Working Group members
for some or most of the period of preparation of this specification, and its
predecessors:
- Mikael Nilsson, Ericsson Infotech
- Ulrich Kauschke, T-Mobil
- Ann Navarro, HTML Writers Guild
- Brad Topol, IBM
- Franklin Reynolds, Nokia
- Graham Klyne, Baltimore Technologies
- Noboru Iwayama, Fujitsu Laboratories LTD
- Takashi Nishigaya, Fujitsu Laboratories LTD
- Lalitha Surayanrayana, SBC Technology Resources
- Hidetaka Ohto, W3C (through March 2002) / Panasonic
- Simon McBride, DSTC Pty Ltd
- Varuni Witana, DSTC Pty Ltd
- Chris Woodrow, Information Architects
- Johan Hjelm, Ericsson
- Barry Briggs, Interleaf
- Gerd Hoelzing, SAP
- Ted Hardie, Equinix
- Serge Rigori, Sun
- Ted Wugofski, Phone.com
- Kynn Bartlett, HTML Writers Guild
- Sandeep Singhal, IBM
- Thorsten Kassing, T-Mobil
- Larry Masinter, Adobe
During the period when the CC/PP WG was developing the specification,
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 first last call
draft.
Following the handing over of the work to the DI WG, special thanks are
also due to David Ezell (XML Schema WG), Brian McBride (RDF Core WG),
Masayasu Ishikawa (HTML WG), and Lynne Rosenthal (QA WG) for their help in
completing the specification.
The following members of the DI WG also provided assistance in completing
the specification: Stephane Boyera, Roger Gimson, Kazuhiro Kitagawa, Andreas
Schade.
7.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 6 October 2000: http://www.w3.org/TR/2000/REC-xml-20001006
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 14 January 1999: http://www.w3.org/TR/1999/REC-xml-names-19990114/
- [RDF]
- Resource Description Framework (RDF) Model and Syntax Specification;
Ora Lassila, Ralph Swick; World Wide Web Consortium Recommendation 22
February 1999: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
- [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/2003/WD-rdf-syntax-grammar-20030123/
7.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: UAProf
User Agent Profiling Specification (1999) as amended by WAP-174_100
User Agent Profiling Specification Information Note (2001) Wireless
Application Protocol Forum available at http://www.wapforum.org/what/technical_1_2.htm
Also see WAP-248-UAProf Version 20-Oct-2001 available at http://www.wapforum.org/what/technical.htm
- [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; World Wide Web
Consortium Recommendation 2 May 2001: http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/
- [XMLSCHEMA-1]
- XML Schema. Part 1: Structures; Henry S. Thompson, David Beech,
Murray Maloney, Noah Mendelsohn; World Wide Web Consortium
Recommendation 2 May 2001: http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
- [XMLSCHEMA-2]
- XML Schema. Part 2: Datatypes; Paul V. Biron, Ashok Malhotra; World
Wide Web Consortium Recommendation 2 May 2001: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
- [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矍.
Mart쭥z (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; World Wide
Web Consortium Working Draft 21 July 2000: http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/
- [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 World Wide
Web Consortium 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 24 June 1999: http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624
- [WAI]
- Web Content Accessibility Guidelines 2.0; Wendy Chisholm, Jason
White, Gregg Vanderheiden; World Wide Web Consortium Working Draft 22
August 2002: http://www.w3.org/TR/2002/WD-WCAG20-20020822/
- [RDFPRIMER]
- RDF Primer; Frank Manola, Eric Miller; World Wide Web Consortium
Working Draft 23 January 2003: http://www.w3.org/TR/2003/WD-rdf-primer-20030123/
Appendix 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 |
Appendix 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: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-2: CC/PP structural properties
ccpp:component Domain=ccpp: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.
</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).
</rdfs:comment>
</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 is the class of RDF Literals that represent CC/PP
attribute string values.
</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 is the class of RDF Literals that represent CC/PP
attribute integer number values.
</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;Litera |