Composite Capability/Preference Profiles (CC/PP):
Structure and Vocabularies
- This version:
- http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/
- http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030728/
- Latest version:
- http://www.w3.org/TR/CCPP-struct-vocab/
- Previous version:
- http://www.w3.org/TR/2002/WD-CCPP-struct-vocab-20021108/
- http://www.w3.org/TR/2003/WD-CCPP-struct-vocab-20030325/
- 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 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
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.
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.
This is a Working Draft of
the W3C showing the changes made as a result of feedback received
on the Last Call
Working Draft. All outstanding issues have been resolved as
shown in the Issues
List.
This specification was originated by the W3C
CC/PP Working Group and has now been passed to the W3C Device
Independence Working Group to carry forward towards a
Recommendation.
The Device Independence Working Group expects
to request that the Director advance this specification to Proposed
Recommendation. The exit criteria of at least two interoperable
implementations over every feature has been satisfied. A report
documenting the results of running implementations against the
Test Suite
will be made available.
Changes made since the Last Call are shown
in a
changes document. The review period for the changes made since
the Last Call Working Draft ends two weeks after publication of
this WD. 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.
Publication as a Proposed Recommendation does
not imply endorsement by the W3C Membership. This is a draft
document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as
other than "work in progress."
Patent disclosures relevant to this specification may be found
on the CC/PP Working Group's patent disclosure page in
conformance with W3C policy.
The Device Independence 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 Device
Independence Working Group Home Page (Member-only
link).
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.
A list of current W3C Recommendations and other technical
documents can be found at http://www.w3.org/TR/.
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 and/or optionally a
proxy to describe their
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, any valid UAProf profile is intended to
be a valid CC/PP profile 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 is 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. 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 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 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 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.
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. 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 a number of
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.03.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.03.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 properties 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:default
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.03.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/softwareProfileschema#SoftwarePlatform" />
<ccpp:defaults
rdf:resource="http://www.example.com/schemasoftwareProfile#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/TterminalProfile#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.03.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/schemahardwareProfile#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/profilehardwareProfile#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
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.
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 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 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
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.
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 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 can
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 data
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--> { "3.0", "4.0", "XHTML" "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.03.2", "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" "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.03.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.03.2</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>2.0</rdf:li>
<rdf:li>3.03.2</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.03.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 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.03.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 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] [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.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).
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].
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.
A common requirement is that the value of a
CC/PP attribute is some resource identified by a URI reference,
e.g. a device type or an applicable DTD or schema. 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].
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. 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.
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"
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"
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)*
|
Integer values are based on the "int" XML
schema datatype [XMLSCHEMA-2].
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 -- 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/">
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-9]+)?[-+]?[0-9]+(/0*[1-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.
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-56 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 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.
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 a vocabulary conforming to 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:type statements. See
section 3.1.
- Components MUST be associated with the CC/PP namespace or some
subclass thereof. 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 associated with the CC/PP namespace or some
subclass thereof. 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 Text 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, depending on the treatment of invalid profiles:
- validating: A consumer
is a CC/PP conformant validating consumer when it rejects
all non-conformant CC/PP documents.
- non-validating: The
behaviour of non-validating CC/PP conformant
consumers is not specified when presented with non-conformant CC/PP
documents.
NOTE: A consumer
implementation may be configurable to act as either a validating or
a non-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 (validating or non-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
56. 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 all most 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
W3C (through March 2002) /
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
During the period when the CC/PP WG was
developing the specification, uUseful 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.
67.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
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:
http://www.w3.org/TR/REC-xml-names
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: http://www.w3.org/TR/REC-rdf-syntax
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/rdf-syntax-grammar/
http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/
67.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>
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
- 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;
W3C World Wide Web
Consortium Proposed
Recommendation: http://www.w3.org/TR/xmlschema-0/
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; W3C
World Wide Web Consortium
Proposed Recommendation: http://www.w3.org/TR/xmlschema-1/
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;
W3C World Wide Web
Consortium Proposed
Recommendation: http://www.w3.org/TR/xmlschema-2/
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é 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 World Wide Web
Consortium Working Draft: http://www.w3.org/TR/CCPP-ra/
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
W3C 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: http://www.w3.org/TR/NOTE-CCPPexchange
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: http://www.w3.org/TR/WCAG20/
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/rdf-primer/
http://www.w3.org/TR/2003/WD-rdf-primer-20030123/
A.
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