You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4076 lines
184 KiB
4076 lines
184 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
|
"http://www.w3.org/TR/html4/loose.dtd">
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
<title>Composite Capability/Preference Profiles (CC/PP): Structure and
|
|
Vocabularies 1.0</title>
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-REC">
|
|
</head>
|
|
|
|
<body lang="en">
|
|
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home"
|
|
alt="W3C" border="0" height="48" width="72"></a>
|
|
|
|
<h1>Composite Capability/Preference Profiles (CC/PP): Structure and
|
|
Vocabularies 1.0</h1>
|
|
|
|
<h2>W3C Recommendation 15 January 2004</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/">http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/CCPP-struct-vocab/">http://www.w3.org/TR/CCPP-struct-vocab/</a></dd>
|
|
<dt>Previous version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/">http://www.w3.org/TR/2003/PR-CCPP-struct-vocab-20031015/</a></dd>
|
|
<dt>Editors:</dt>
|
|
<dd>Graham Klyne, <a href="mailto:GK@acm.org">GK@acm.org</a>, Nine by
|
|
Nine</dd>
|
|
<dd>Franklin Reynolds, <a
|
|
href="mailto:franklin.reynolds@nokia.com">franklin.reynolds@nokia.com</a>,
|
|
Nokia Research Center</dd>
|
|
<dd>Chris Woodrow, <a
|
|
href="mailto:woodroc@metaphoria.net">woodroc@metaphoria.net</a>,
|
|
Information Architects</dd>
|
|
<dd>Hidetaka Ohto, <a href="mailto:ohto@w3.org">ohto@w3.org</a>, W3C
|
|
(through March 2002) / Panasonic</dd>
|
|
<dd>Johan Hjelm, <a
|
|
href="mailto:johan.hjelm@ericsson.com">Johan.hjelm@ericsson.com</a>,
|
|
Ericsson</dd>
|
|
<dd>Mark H. Butler, <a
|
|
href="mailto:mark-h_butler@hp.com">mark-h_butler@hp.com</a>,
|
|
Hewlett-Packard</dd>
|
|
<dd>Luu Tran, <a href="mailto:luu.tran@sun.com">luu.tran@sun.com</a>, Sun
|
|
Microsystems</dd>
|
|
</dl>
|
|
|
|
<p>Please refer to the <a
|
|
href="/2003/07/ccpp-SV-PR/errata/"><strong>errata</strong></a> for this
|
|
document, which may include some normative corrections.</p>
|
|
|
|
<p>The English version of this specification is the only normative version.
|
|
Non-normative <a href="/2003/07/ccpp-SV-PR/translation/">translations</a> may
|
|
also be available. </p>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004
|
|
<a href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
|
|
href="http://www.lcs.mit.edu/"><abbr
|
|
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
|
|
href="http://www.ercim.org/"><abbr
|
|
title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
|
|
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>,
|
|
<a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
|
|
use</a>, and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software">software
|
|
licensing</a> rules apply.</p>
|
|
<hr title="Separator for header">
|
|
</div>
|
|
|
|
<h2><a name="abstract"></a>Abstract</h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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:</p>
|
|
<ul>
|
|
<li>structure of client capability and preference descriptions, AND</li>
|
|
<li>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.</li>
|
|
</ul>
|
|
|
|
<p>CC/PP vocabulary is identifiers (URIs) used to refer to specific
|
|
capabilities and preferences, and covers:</p>
|
|
<ul>
|
|
<li>the types of values to which CC/PP attributes may refer,</li>
|
|
<li>an appendix describing how to introduce new vocabularies,</li>
|
|
<li>an appendix giving an example small client vocabulary covering print
|
|
and display capabilities, and</li>
|
|
<li>an appendix providing a survey of existing work from which new
|
|
vocabularies may be derived.</li>
|
|
</ul>
|
|
|
|
<h2><a name="DocumentStatus"></a>Status of this document</h2>
|
|
|
|
<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a>
|
|
at http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/2003/07/ccpp-SV-PR/test-suite-20030827/">test
|
|
suite</a> for has been developed, along with an <a
|
|
href="http://www.w3.org/2003/07/ccpp-SV-PR/test-suite-20030827/implementation-report.html">implementation
|
|
report</a>.</p>
|
|
|
|
<p>This document has been produced by the W3C Device Independence Working
|
|
Group as part of the <a href="/2001/di/Activity">Device Independence
|
|
Activity</a> within the <a href="http://www.w3.org/Interaction/">W3C
|
|
Interaction Domain</a>. Continued status of the work is reported on the <a
|
|
href="/2001/di/Group/">Device Independence Working Group Home Page</a> (<a
|
|
href="http://cgi.w3.org/MemberAccess/AccessRequest">Member-only link</a>).</p>
|
|
|
|
<p>The public is invited to send comments or reports errors to the editors at
|
|
<a href="mailto:www-mobile@w3.org">www-mobile@w3.org</a>, the public forum
|
|
for discussion of W3C's work on Mobile Web Access. An archive is available at
|
|
<a
|
|
href="http://lists.w3.org/Archives/Public/www-mobile/">http://lists.w3.org/Archives/Public/www-mobile/</a>.</p>
|
|
|
|
<p>Patent disclosures relevant to this specification may be found on the
|
|
CC/PP Working Group's <a href="/Mobile/CCPP/disclosures.html">patent
|
|
disclosure page</a> in conformance with W3C policy.</p>
|
|
|
|
<h2><a name="TableOfContents"></a>Table of contents</h2>
|
|
<ul>
|
|
<li><a href="#Introduction"><strong>1. Introduction</strong></a>
|
|
<ul>
|
|
<li><a href="#ScopeOfDocument">1.1 Scope and normative elements</a></li>
|
|
<li><a href="#StructureOfDoc">1.2 Structure of this document</a></li>
|
|
<li><a href="#DocumentConventions">1.3 Document conventions</a>
|
|
<ul>
|
|
<li><a href="#TerminologyConventions">1.3.1 Terminology</a></li>
|
|
<li><a href="#RDFGraphNotation">1.3.2 RDF graph notation</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#CCPPArchitecture"><strong>2. CC/PP architecture</strong></a>
|
|
<ul>
|
|
<li><a href="#CCPPProfileStructOverview">2.1 CC/PP profile structure</a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666512">2.1.1 Profile components</a></li>
|
|
<li><a href="#xtocid-33666513">2.1.2 Component attributes</a></li>
|
|
<li><a href="#xtocid-33666514">2.1.3 Defaults</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#ExtensibilityNamespaces">2.2 Extensibility and
|
|
namespaces</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#CCPPStructure"><strong>3. CC/PP structure</strong></a>
|
|
<ul>
|
|
<li><a href="#ProfileComponents">3.1 Components</a></li>
|
|
<li><a href="#ProfileAttributes">3.2 Attributes</a></li>
|
|
<li><a href="#ProfileDefaults">3.3 Defaults</a></li>
|
|
<li><a href="#DistinguishStructAttrib">3.4 Distinguishing profile
|
|
structure from attributes</a></li>
|
|
<li><a href="#RDFUsage">3.5 Notes on RDF usage</a></li>
|
|
<li><a href="#xtocid-58647528">3.6 RDF graph composition</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#AttributeVocabularies"><strong>4. Attribute
|
|
vocabularies</strong></a>
|
|
<ul>
|
|
<li><a href="#AttributeData">4.1 Attribute data</a>
|
|
<ul>
|
|
<li><a href="#SimpleAttribute">4.1.1 Simple CC/PP attribute data</a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666539">4.1.1.1 Strings</a></li>
|
|
<li><a href="#xtocid-33666543">4.1.1.2 Integer numbers</a></li>
|
|
<li><a href="#xtocid-33666544">4.1.1.3 Rational numbers</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#ComplexAttribute">4.1.2 Complex CC/PP attribute
|
|
data</a>
|
|
<ul>
|
|
<li><a href="#4.1.2.1">4.1.2.1 Set of values</a></li>
|
|
<li><a href="#4.1.2.2">4.1.2.2 Sequence of values</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#xtocid-33666547">4.2 Attribute identifiers</a></li>
|
|
<li><a href="#xtocid-33666548">4.3 RDF vocabulary schema</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Conformance"><strong>5. Conformance</strong></a>
|
|
<ul>
|
|
<li><a href="#ConformanceDocument">5.1 CC/PP Document
|
|
Conformance</a></li>
|
|
<li><a href="#ConformanceProducer">5.2 CC/PP Producer
|
|
Conformance</a></li>
|
|
<li><a href="#ConformanceConsumer">5.3 CC/PP Consumer
|
|
Conformance</a></li>
|
|
<li><a href="#ConformanceClaims">5.4 Conformance Claims</a>
|
|
<ul>
|
|
<li><a href="#ConformanceClaimsValidity">5.4.1 Validity</a></li>
|
|
<li><a href="#ConformanceClaimsWellformed">5.4.2
|
|
Well-formed</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Acknowledgements"><strong>6. Acknowledgments</strong></a></li>
|
|
<li><a href="#xtocid-33666550"><strong>7. References</strong></a>
|
|
<ul>
|
|
<li><a href="#norm_refs">7.1 Normative References</a></li>
|
|
<li><a href="#inform_refs">7.2 Informative References</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_A"><strong>Appendix A: Terminology and
|
|
abbreviations</strong></a>
|
|
<ul>
|
|
<li><a href="#Terminology">A.1 Terminology</a></li>
|
|
<li><a href="#Abbreviations">A.2 Abbreviations</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_B"><strong>Appendix B: RDF schema for
|
|
structure</strong></a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666555">B.1 Summary of CC/PP class
|
|
hierarchy</a></li>
|
|
<li><a href="#xtocid-33666556">B.2 Summary of CC/PP properties</a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666557">Structural properties (instances of
|
|
<tt>ccpp:Property</tt>)</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#xtocid-33666558">B.3 RDF Schema</a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666559">CC/PP core and class
|
|
structure:</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_C"><strong>Appendix C: CC/PP attribute vocabulary
|
|
for print and display</strong></a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666562">Client attribute properties (instances
|
|
of <tt>ccpp:Attribute</tt>)</a></li>
|
|
<li><a href="#xtocid-62790564">Schema for client vocabulary</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_D"><strong>Appendix D: Recommendations for creating
|
|
a vocabulary</strong></a>
|
|
<ul>
|
|
<li><a href="#Basic">D.1 Basic format for all vocabulary items</a></li>
|
|
<li><a href="#namespaces">D.2 Use of XML namespaces</a></li>
|
|
<li><a href="#Principles">D.3 Principles for defining new attributes</a>
|
|
<ul>
|
|
<li><a href="#xtocid-33666567">D.3.1 If possible, reuse existing
|
|
vocabularies</a></li>
|
|
<li><a href="#3.3.2">D.3.2 Attribute value type and
|
|
interpretation</a></li>
|
|
<li><a href="#3.3.3">D.3.3 Interpretation not dependent on other
|
|
attribute values</a></li>
|
|
<li><a href="#3.3.4">D.3.4 Attribute naming conventions</a></li>
|
|
<li><a href="#AttributeApplicability">D.3.5 Attributes should have
|
|
specific applicability</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#ProtocolInteractions">D.4 Protocol interactions</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_E"><strong>Appendix E: Review of applicable
|
|
vocabularies</strong></a>
|
|
<ul>
|
|
<li><a href="#IETF">E.1 IETF media feature registration
|
|
(CONNEG)</a></li>
|
|
<li><a href="#UAPROF">E.2 WAP UAProf</a></li>
|
|
<li><a href="#TIFF">E.3 TIFF</a></li>
|
|
<li><a href="#WAVE">E.4 WAVE</a></li>
|
|
<li><a href="#MPEG-4">E.5 MPEG-4</a></li>
|
|
<li><a href="#MPEG-7">E.6 MPEG-7</a></li>
|
|
<li><a href="#PWG">E.7 PWG</a></li>
|
|
<li><a href="#Salutation">E.8 Salutation</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_F"><strong>Appendix F: CC/PP
|
|
applications</strong></a>
|
|
<ul>
|
|
<li><a href="#Outline">F.1 Outline of request processing in
|
|
HTTP</a></li>
|
|
<li><a href="#ProtocolAssumptions">F.2 Protocol assumptions for proxy
|
|
behavior</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#Appendix_G"><strong>Appendix G: RDF Compatibility</strong></a>
|
|
<ul>
|
|
<li><a href="#RDFImplicitDatatyping">G.1 Implicit datatyping</a></li>
|
|
<li><a href="#RDFExplicitDatatyping">G.2 Explicit datatyping</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#RevisionHistory"><strong>Appendix W: Revision
|
|
history</strong></a></li>
|
|
</ul>
|
|
|
|
<h2><a name="Introduction"></a>1. Introduction</h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 '<code>accept</code>' headers and HTML '<code>alt=</code>'
|
|
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.</p>
|
|
|
|
<p>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 <a href="#2">[XMLNAMESPACES]</a>, and
|
|
interoperability. There is a specification that describes how to encode RDF
|
|
using XML <a href="#3">[RDF]</a>, and another that defines an RDF schema
|
|
description language using RDF <a href="#4">[RDFSCHEMA]</a>. 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 <a
|
|
href="#rdfprimer">[RDFPRIMER]</a>. Note that the <a
|
|
href="#rdfprimer">[RDFPRIMER]</a> document describes a more recent revision
|
|
of the RDF specifications than the ones on which this specification is
|
|
based.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <a href="#Appendix_F">Appendix F</a>, (CC/PP applications).</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>CC/PP is designed to be broadly compatible with the earlier UAProf
|
|
specification <a href="#9">[UAPROF]</a> from the WAP Forum. That is, we have
|
|
attempted to accomodate existing UAProf profiles.</p>
|
|
|
|
<p>CC/PP is compatible with IETF media feature sets (CONNEG) <a
|
|
href="#6">[RFC2533]</a> 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.</p>
|
|
|
|
<p>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 <a href="#37">[WAI]</a>.</p>
|
|
|
|
<h3><a name="ScopeOfDocument"></a>1.1 Scope and normative elements</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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. <a href="#Appendix_F">Appendix F</a> contains some further
|
|
discussion of CC/PP applications.</p>
|
|
|
|
<p>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 <a href="#Conformance">5</a>). 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.</p>
|
|
|
|
<p>The architecture <a href="#CCPPArchitecture">section</a> 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.</p>
|
|
|
|
<p>The section on <a href="#CCPPStructure">CC/PP structure</a> covers two
|
|
main areas:</p>
|
|
<ul>
|
|
<li>CC/PP profile components: support for these is REQUIRED.</li>
|
|
<li>CC/PP profile defaults: support for these is REQUIRED.</li>
|
|
</ul>
|
|
|
|
<p>The <a href="#AttributeVocabularies">section</a> 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.</p>
|
|
|
|
<p>Support is not required for any specific vocabulary, but application
|
|
designers are strongly encouraged to re-use existing vocabularies where
|
|
possible.</p>
|
|
|
|
<p>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 <a
|
|
href="#Appendix_B">Appendix B</a> (new CC/PP attributes are instances of
|
|
<code><i>ccpp</i>:Attribute</code>, new component classes are subclasses of
|
|
<code><i>ccpp</i>:Component</code>, etc.).</p>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE:</i></b> 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.</p>
|
|
</blockquote>
|
|
|
|
<h3><a name="StructureOfDoc"></a>1.2 Structure of this document</h3>
|
|
|
|
<p>The remainder of this section covers terminology, conventions and
|
|
notations used in this document.</p>
|
|
|
|
<p>Section 2, <a href="#CCPPArchitecture"><strong>CC/PP
|
|
architecture</strong></a>, provides an overview of the CC/PP profile
|
|
structure and use of XML namespaces.</p>
|
|
|
|
<p>Section 3, <a href="#CCPPStructure"><strong>CC/PP structure</strong></a>,
|
|
describes the structure of a CC/PP profile, and introduces the RDF elements
|
|
that are used to create the essential CC/PP elements.</p>
|
|
|
|
<p>Section 4, <a href="#AttributeVocabularies"><strong>Attribute
|
|
vocabularies</strong></a>, describes how attributes are used in a CC/PP
|
|
profile, and presents the recommended structure of CC/PP elements used to
|
|
describe specific features.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3><a name="DocumentConventions"></a>1.3 Document conventions</h3>
|
|
|
|
<h4><a name="TerminologyConventions"></a>1.3.1 Terminology</h4>
|
|
|
|
<p>See <cite>CC/PP terminology and abbreviations</cite> in <a
|
|
href="#Appendix_A">Appendix A</a> of this document.</p>
|
|
|
|
<p>The term "<dfn>CC/PP attribute</dfn>" 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 "<dfn>feature</dfn>" refers to a client capability or
|
|
characteristic that may or may not be the basis of a CC/PP attribute. The
|
|
term "<dfn>attribute name</dfn>" is used to indicate an RDF property name
|
|
used to identify a CC/PP attribute.</p>
|
|
|
|
<p>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 <a href="#25">[RFC2119]</a>.</p>
|
|
|
|
<h4><a name="RDFGraphNotation"></a>1.3.2 RDF graph notation</h4>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 1-1" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 1-1: RDF graph notation</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>Subject-resource</i>] --<i>propertyName</i>--> [<i>Object-resource</i>]</pre>
|
|
|
|
<blockquote>
|
|
Indicates a graph edge labeled '<i>propertyName</i>' from an RDF
|
|
resource named 'Subject-resource' to another RDF resource named
|
|
'<i>Object-resource</i>'.</blockquote>
|
|
<pre>[<i>Subject-resource</i>] --<i>propertyName</i>--> "<i>Property value</i>"</pre>
|
|
|
|
<blockquote>
|
|
Indicates a graph edge labeled 'propertyName' from an RDF resource
|
|
named 'Subject-resource' to a literal string containing the
|
|
indicated value.</blockquote>
|
|
<pre>[<i>Subject-resource</i>] --<i>propertyName</i>--> { "<i>Val1</i>", "<i>Val2</i>", ... }</pre>
|
|
|
|
<blockquote>
|
|
This is a shorthand for a property whose value is an
|
|
<tt>rdf:Bag</tt> resource containing the indicated values (see
|
|
section <a href="#4.1.2.1">4.1.2.1</a>).</blockquote>
|
|
<pre>[<<i>Subject-type</i>>] --<i>propertyName</i>--> [<<i>Object-type</i>>]</pre>
|
|
|
|
<blockquote>
|
|
Names in angle brackets are used to indicate an RDF resource of the
|
|
indicated type (i.e. having the indicated <tt>rdf:Type</tt>
|
|
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.</blockquote>
|
|
<pre>[<i>Subject-resource</i>] --<i>propertyName</i>--> [<i>Object-resource</i>]
|
|
|
|
|
-------------------------------
|
|
|
|
|
+--<i>property1</i>--> <i>(val1)</i>
|
|
+--<i>property2</i>--> <i>(val2)</i>
|
|
:
|
|
(etc.)</pre>
|
|
|
|
<blockquote>
|
|
Property arcs can be chained, and multiple arcs drawn from a
|
|
subject resource.</blockquote>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Here are some XML examples of the RDF graph structures described above:</p>
|
|
|
|
<table summary="Figure 1-2" border="1" width="0%" bgcolor="#CCFFCC">
|
|
<caption align="bottom">Figure 1-2: RDF graph example in XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre><?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#">
|
|
|
|
<!-- [<i>Subject-resource</i>] -<i>propertyName</i>-> [<i>Object-resource</i>]
|
|
-->
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Subject-resource</i>">
|
|
<<i>propertyName</i>>
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Object-resource</i>" />
|
|
</<i>propertyName</i>>
|
|
</rdf:Description>
|
|
|
|
<!-- [<i>Subject-resource</i>] -<i>propertyName</i>-> [<i>Object-resource</i>]
|
|
- (Alternative format)
|
|
-->
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Subject-resource</i>">
|
|
<<i>propertyName</i>
|
|
rdf:resource="<i>http://www.example.com/schema#Object-resource</i>" />
|
|
</rdf:Description>
|
|
|
|
<!-- [<i>Subject-resource</i>] -<i>propertyName</i>-> "<i>property value</i>"
|
|
-->
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Subject-resource</i>">
|
|
<<i>propertyName</i>><i>property value</i></<i>propertyName</i>>
|
|
</rdf:Description>
|
|
|
|
<!-- [<i>Subject-resource</i>] -<i>propertyName</i>-> { "<i>Val1</i>", "<i>Val2</i>", ... }
|
|
-->
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Subject-resource</i>">
|
|
<<i>propertyName</i>>
|
|
<rdf:Description>
|
|
<rdf:type
|
|
rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" />
|
|
<rdf:li><i>Val1</i></rdf:li>
|
|
<rdf:li><i>Val1</i></rdf:li>
|
|
|
|
<!-- ...etc... -->
|
|
|
|
</rdf:Description>
|
|
</<i>propertyName</i>>
|
|
</rdf:Description>
|
|
|
|
<!-- [<i>Subject-resource</i>] -<i>propertyName</i>-> { "<i>Val1</i>", "<i>Val2</i>", ... }
|
|
- (Alternative format)
|
|
-->
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Subject-resource</i>">
|
|
<<i>propertyName</i>>
|
|
<rdf:Bag>
|
|
<rdf:li><i>Val1</i></rdf:li>
|
|
<rdf:li><i>Val1</i></rdf:li>
|
|
|
|
<!-- ...etc... -->
|
|
|
|
</rdf:Bag>
|
|
</<i>propertyName</i>>
|
|
</rdf:Description>
|
|
|
|
<!-- [<<i>Subject-type</i>>] -<i>propertyName</i>-> [<<i>Object-type</i>>]
|
|
-->
|
|
<rdf:Description>
|
|
<rdf:type
|
|
rdf:resource="<i>http://www.example.com/schema#Subject-type</i>" />
|
|
<<i>propertyName</i>>
|
|
<rdf:Description>
|
|
<rdf:type
|
|
rdf:resource="<i>http://www.example.com/schema#Object-type</i>" />
|
|
</rdf:Description>
|
|
</<i>propertyName</i>>
|
|
</rdf:Description></pre>
|
|
<pre> <!-- [<i>Subject-resource</i>] -<i>propertyName</i>-> [<i>Object-resource</i>]
|
|
- |
|
|
- +-<i>property1</i>-> <i>(val1)</i>
|
|
- +-<i>property2</i>-> <i>(val2)</i>
|
|
- :
|
|
-->
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Subject-resource</i>">
|
|
<<i>propertyName</i>>
|
|
<rdf:Description
|
|
rdf:about="<i>http://www.example.com/profile#Object-resource</i>" >
|
|
<<i>property1</i>><i>val1</i></<i>property1</i>>
|
|
<<i>property2</i>><i>val2</i></<i>property2</i>>
|
|
|
|
<!-- ...etc... -->
|
|
|
|
</rdf:Description>
|
|
</<i>propertyName</i>>
|
|
</rdf:Description>
|
|
|
|
</rdf:RDF></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2><a name="CCPPArchitecture"></a>2. CC/PP architecture</h2>
|
|
|
|
<p>This section is not normative, but provides an overview of the features of
|
|
CC/PP.</p>
|
|
|
|
<h3><a name="CCPPProfileStructOverview"></a>2.1 CC/PP profile structure</h3>
|
|
|
|
<p>A CC/PP profile is broadly constructed as a 2-level hierarchy:</p>
|
|
<ul>
|
|
<li>a profile having at least one or more <dfn>components</dfn>, and</li>
|
|
<li>each component having at least one or more <dfn>attributes</dfn>.</li>
|
|
</ul>
|
|
|
|
<h4><a name="xtocid-33666512">2.1.1 Profile components</a></h4>
|
|
|
|
<p>The initial branches of the CC/PP profile tree describe major components
|
|
of the client. Examples of major components are:</p>
|
|
<ul>
|
|
<li>the hardware platform upon which software is executing,</li>
|
|
<li>the software platform upon which all applications are hosted, or</li>
|
|
<li>an individual application, such as a browser.</li>
|
|
</ul>
|
|
|
|
<p>A simple, graphical representation of the bottom of a CC/PP tree based on
|
|
three components (<code>TerminalHardware</code>,
|
|
<code>TerminalSoftware</code> and <code>TerminalBrowser</code>) would be:</p>
|
|
|
|
<table summary="Figure 2-1a" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 2-1a: CC/PP profile components</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>example</i>:MyProfile]
|
|
|
|
|
+--<i>ccpp</i>:component-->[<i>example</i>:TerminalHardware]
|
|
+--<i>ccpp</i>:component-->[<i>example</i>:TerminalSoftware]
|
|
+--<i>ccpp</i>:component-->[<i>example</i>:TerminalBrowser]</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>The corresponding XML might look like this:</p>
|
|
|
|
<table summary="Figure 2-1b" border="1" width="0%" bgcolor="#CCFFCC">
|
|
<caption align="bottom">Figure 2-1b: CC/PP profile components in
|
|
XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h4><a name="xtocid-33666513">2.1.2 Component attributes</a></h4>
|
|
|
|
<p>A CC/PP profile describes client capabilities and preferences in terms of
|
|
a number of "CC/PP attributes" for each component.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 2-2a" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 2-2a: Complete CC/PP profile
|
|
example</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>ex</i>:MyProfile]
|
|
|
|
|
+--<i>ccpp</i>:component-->[<i>ex</i>:TerminalHardware]
|
|
| |
|
|
| +--<i>rdf</i>:type----> [<i>ex</i>:HardwarePlatform]
|
|
| +--<i>ex</i>:displayWidth--> "320"
|
|
| +--<i>ex</i>:displayHeight--> "200"
|
|
|
|
|
+--<i>ccpp</i>:component-->[<i>ex</i>:TerminalSoftware]
|
|
| |
|
|
| +--<i>rdf</i>:type----> [<i>ex</i>:SoftwarePlatform]
|
|
| +--<i>ex</i>:name-----> "EPOC"
|
|
| +--<i>ex</i>:version--> "2.0"
|
|
| +--<i>ex</i>:vendor---> "Symbian"
|
|
|
|
|
+--<i>ccpp</i>:component-->[<i>ex</i>:TerminalBrowser]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:BrowserUA]
|
|
+--<i>ex</i>:name-----> "Mozilla"
|
|
+--<i>ex</i>:version--> "5.0"
|
|
+--<i>ex</i>:vendor---> "Symbian"
|
|
+--<i>ex</i>:htmlVersionsSupported--> [ ]
|
|
|
|
|
----------------------------
|
|
|
|
|
+--<i>rdf</i>:type---> [<i>rdf</i>:Bag]
|
|
+--<i>rdf</i>:_1-----> "3.2"
|
|
+--<i>rdf</i>:_2-----> "4.0"</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>The corresponding XML might look like this:</p>
|
|
|
|
<table summary="Figure 2-2b" border="1" width="0%" bgcolor="#CCFFCC">
|
|
<caption align="bottom">Figure 2-2b: Complete CC/PP profile example in
|
|
XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h4><a name="xtocid-33666514">2.1.3 Defaults</a></h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Default values for a component of a CC/PP profile are indicated by a
|
|
<code><i>ccpp</i>:defaults</code> arc from the component concerned to a
|
|
component that describes the default values.</p>
|
|
|
|
<table summary="Figure 2-3a" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 2-3a: CC/PP profile using defaults</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>ex</i>:MyProfile]
|
|
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalHardware]
|
|
| |
|
|
| +--<i>rdf</i>:type-------> [<i>ex</i>:HardwarePlatform]
|
|
| +--<i>ccpp</i>:defaults--> [<i>ex</i>:HWDefault]
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalSoftware]
|
|
| |
|
|
| +--<i>rdf</i>:type-------> [<i>ex</i>:SoftwarePlatform]
|
|
| +--<i>ccpp</i>:defaults--> [<i>ex</i>:SWDefault]
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalBrowser]
|
|
|
|
|
+--<i>rdf</i>:type-------> [<i>ex</i>:BrowserUA]
|
|
+--<i>ccpp</i>:defaults--> [<i>ex</i>:UADefault]
|
|
|
|
[<i>ex</i>:HWDefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:HardwarePlatform]
|
|
+--<i>ex</i>:displayWidth--> "320"
|
|
+--<i>ex</i>:displayHeight--> "200"
|
|
|
|
[<i>ex</i>:SWDefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:SoftwarePlatform]
|
|
+--<i>ex</i>:name-----> "EPOC"
|
|
+--<i>ex</i>:version--> "2.0"
|
|
+--<i>ex</i>:vendor---> "Symbian"
|
|
|
|
[<i>ex</i>:UADefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:BrowserUA]
|
|
+--<i>ex</i>:name-----> "Mozilla"
|
|
+--<i>ex</i>:version--> "5.0"
|
|
+--<i>ex</i>:vendor---> "Symbian"
|
|
+--<i>ex</i>:htmlVersionsSupported--> [ ]
|
|
|
|
|
+--<i>rdf</i>:type---> [<i>rdf</i>:Bag]
|
|
+--<i>rdf</i>:_1-----> "3.2"
|
|
+--<i>rdf</i>:_2-----> "4.0"</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>The corresponding XML might look like this:</p>
|
|
|
|
<table summary="Figure 2-3b" border="1" width="0%" bgcolor="#CCFFCC"
|
|
cellpadding="3">
|
|
<caption align="bottom">Figure 2-3b: CC/PP profile using defaults in
|
|
XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Device profile referencing defaults:</b>
|
|
<pre><?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></pre>
|
|
<b>Defaults for HardwarePlatform:</b>
|
|
<pre><?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></pre>
|
|
<b>Defaults for SoftwarePlatform:</b>
|
|
<pre><?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></pre>
|
|
<b>Defaults for BrowserUA:</b>
|
|
<pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>If a given attribute value is applied directly to a component resource,
|
|
and also appears on a resource referenced by the
|
|
<i><code>ccpp</code></i><code>:defaults</code> property, the directly applied
|
|
value takes precedence:</p>
|
|
|
|
<table summary="Figure 2-4a" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 2-4a: Overriding a default value</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>ex</i>:MyProfile]
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalHardware]
|
|
|
|
|
+--<i>rdf</i>:type--------> [<i>ex</i>:HardwarePlatform]
|
|
+--<i>ccpp</i>:defaults---> [<i>ex</i>:HWDefault]
|
|
+--<i>ex</i>:memoryMb-------> "32"
|
|
|
|
[<i>ex</i>:HWDefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:HardwarePlatform]
|
|
+--ex:displayWidth--> "320"
|
|
+--ex:displayHeight--> "200"
|
|
+--<i>ex</i>:memoryMb---> "16"</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>In this example, the default component indicates 16 Mb of memory, but this
|
|
value is overridden by the <code>memoryMb</code> property applied directly to
|
|
the profile component. Thus, in this profile, the <code>memoryMb</code>
|
|
attribute has a value of 32.</p>
|
|
|
|
<p>The corresponding XML might look like this:</p>
|
|
|
|
<table summary="Figure 2-4b" border="1" width="0%" bgcolor="#CCFFCC"
|
|
cellpadding="3">
|
|
<caption align="bottom">Figure 2-4b: Overriding a default value in
|
|
XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Device profile referencing defaults:</b>
|
|
<pre><?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></pre>
|
|
<b>Defaults for HardwarePlatform:</b>
|
|
<pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>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
|
|
<code>http://example.com/DeviceProfile#HardwarePlatform</code>, the URI
|
|
<code>http://example.com/DeviceProfile</code> is used to retrieve an RDF
|
|
document, and a resource within that document having the local identifier
|
|
<code>#HardwarePlatform</code> is taken as the default resource. (Such a
|
|
resource might be defined within the target document using
|
|
"<code>about='http://example.com/DeviceProfile#HardwarePlatform'</code>" or
|
|
"<code>ID='HardwarePlatform'</code>". See also section <a
|
|
href="#RDFUsage">3.5.</a>)</p>
|
|
|
|
<blockquote>
|
|
<p><i><b>NOTE</b></i>: Individual applications may allow relative URIs to
|
|
be used. Those that do should specify exactly how the corresponding RDF
|
|
document is located.</p>
|
|
</blockquote>
|
|
|
|
<h3><a name="ExtensibilityNamespaces"></a>2.2 Extensibility and
|
|
namespaces</h3>
|
|
|
|
<p>CC/PP is extended primarily through the introduction of new attribute
|
|
vocabularies.</p>
|
|
|
|
<p>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 <a href="#8">[RFC2534]</a>, and serves as an
|
|
example of how CC/PP attribute vocabularies may be defined. Another such
|
|
example is the WAP Forum UAProf specification <a href="#9">[UAPROF]</a>.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>XML namespaces <a href="#2">[XMLNAMESPACES]</a> 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.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 2-7" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 2-7: Example namespace declarations</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCFFCC">
|
|
<td><pre><?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#"></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>The first namespace declaration is for RDF usage. The second declaration
|
|
names the CC/PP core structural vocabulary, which includes
|
|
"<code>component</code>", "<code>defaults</code>" and other properties that
|
|
are intrinsic to the CC/PP framework. The third namespace declaration names a
|
|
component CC/PP properties vocabulary.</p>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE:</i></b> Remember that the namespace prefixes are quite
|
|
arbitrary: applications MUST NOT assume that the prefix <code>rdf:</code>
|
|
refers to the RDF vocabulary, or that <code>ccpp:</code> refers to the
|
|
intrinsic CC/PP vocabulary, etc. It is the URI to which a namespace prefix
|
|
is bound that matters.</p>
|
|
</blockquote>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE:</i></b> 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
|
|
"<code>http://www.wapforum.org/UAPROF/ccppschema-20000405#</code>" 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.</p>
|
|
</blockquote>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The following namespaces are introduced by the CC/PP framework:</p>
|
|
|
|
<p><b><a
|
|
href="/2002/11/08-ccpp-schema">http://www.w3.org/2002/11/08-ccpp-schema</a></b>#</p>
|
|
|
|
<blockquote>
|
|
Normative RDF schema defining class declarations for CC/PP, and core
|
|
structural properties (listed in <a href="#xtocid-33666558">Appendix
|
|
B.3</a>).</blockquote>
|
|
<b><a
|
|
href="/2002/11/08-ccpp-client">http://www.w3.org/2002/11/08-ccpp-client</a></b>#
|
|
|
|
<blockquote>
|
|
Example but non-normative vocabulary for describing simple client
|
|
capabilities, with particular relevance to print and display clients
|
|
(listed in <a href="#Appendix_C">Appendix C</a>).</blockquote>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE:</i></b> To retrieve these schemas it is necessary for your
|
|
browser to add the header <code>Accept:text/xml</code> in the request.
|
|
Browsers that do not add this accept header or use the header
|
|
<code>Accept:*/*</code> or variants thereof will receive a HTML page that
|
|
notes these are namespaces reserved for the CC/PP Schemas.</p>
|
|
</blockquote>
|
|
|
|
<h2><a name="CCPPStructure"></a>3. CC/PP structure</h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3><a name="ProfileComponents"></a>3.1 Components</h3>
|
|
|
|
<p>A CC/PP profile contains one or more <dfn>components</dfn>, and each
|
|
component contains one or more attributes. Each component is represented by a
|
|
resource of type <code><i>ccpp</i>:Component</code> (or some RDFS subclass
|
|
thereof), and related to the client profile resource by a
|
|
<code><i>ccpp</i>:component</code> property. Here, the
|
|
<code><i>ccpp</i></code> namespace is
|
|
http://www.w3.org/2002/11/08-ccpp-schema#. For compatibility with UAProf, the
|
|
namespace used to qualify <code>component</code> MAY be a UAProf
|
|
namespace.</p>
|
|
|
|
<p>The object of a <code><i>ccpp</i>:Component</code> resource MAY have an
|
|
<code><i>rdf</i>:type</code> 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.</p>
|
|
|
|
<p>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 <code><i>rdf</i>:type</code> property, or
|
|
equivalent RDF. A CC/PP processor MUST be able to use this type information
|
|
to disambiguate application of any attribute used.</p>
|
|
|
|
<h3><a name="ProfileAttributes"></a>3.2 Attributes</h3>
|
|
|
|
<p>CC/PP profiles are constructed using RDF <a href="#3">[RDF]</a>. The RDF
|
|
data model represents CC/PP attributes as named <i>properties</i> linking a
|
|
<i>subject</i> resource to an associated <i>object</i> resource or RDF
|
|
literal value.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<table summary="Figure 3-1" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 3-1: RDF statement describing a client
|
|
attribute</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[Client component resource] --attributeName--> (Attribute-value)</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>CC/PP attribute labels are represented by XML name values (per XML
|
|
specification <a href="#1">[XML]</a>, section 2.3), which may include a
|
|
namespace prefix (i.e. a <i>qualified name</i>, per XML namespaces <a
|
|
href="#2">[XMLNAMESPACES]</a>, 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.</p>
|
|
|
|
<p>Attribute values may be of simple or structured data types.</p>
|
|
|
|
<p>Simple data types are discussed in the section <a
|
|
href="#SimpleAttribute">4.1.1</a>. 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.</p>
|
|
|
|
<p>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 <a href="#ComplexAttribute">4.1.2</a>.</p>
|
|
|
|
<h3><a name="ProfileDefaults"></a>3.3 Defaults</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Default values are referenced by the property
|
|
<i><code>ccpp</code></i><code>:defaults</code>. This name conforms to the
|
|
name format recommendations of the RDF model and syntax specification <a
|
|
href="#3">[RDF]</a>, Appendix C.1. However, for compatibility with earlier
|
|
versions of CC/PP used with UAProf, CC/PP processors SHOULD recognize the
|
|
property name <code><i>ccpp</i>:Defaults</code> (i.e. with capital "D") as
|
|
equivalent. Here, the <code><i>ccpp</i></code> namespace is
|
|
http://www.w3.org/2002/11/08-ccpp-schema#. For compatibility with UAProf, the
|
|
namespace used to qualify <code>defaults</code> or <code>Defaults</code> MAY
|
|
be a UAProf namespace.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 3-2a" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 3-2a: CC/PP profile using defaults</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>ex</i>:MyProfile]
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalHardware]
|
|
| |
|
|
| +--<i>rdf</i>:type-------> [<i>ex</i>:HardwarePlatform]
|
|
| +--<i>ccpp</i>:defaults--> [<i>ex</i>:HWDefault]
|
|
| +--<i>ex</i>:displayWidth--> "640"
|
|
| +--<i>ex</i>:displayHeight-> "400"
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalSoftware]
|
|
| |
|
|
| +--<i>rdf</i>:type-------> [<i>ex</i>:SoftwarePlatform]
|
|
| +--<i>ccpp</i>:defaults--> [<i>ex</i>:SWDefault]
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalBrowser]
|
|
|
|
|
------------
|
|
|
|
|
+--<i>rdf</i>:type-------> [<i>ex</i>:BrowserUA]
|
|
+--<i>ccpp</i>:defaults--> [<i>ex</i>:UADefault]
|
|
+--<i>ex</i>:htmlVersionsSupported--> { "2.0", "3.2", "4.0" }
|
|
|
|
[<i>ex</i>:HWDefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:HardwarePlatform]
|
|
+--<i>ex</i>:cpu------> "PPC"
|
|
+--<i>ex</i>:displayWidth--> "320"
|
|
+--<i>ex</i>:displayHeight--> "200"
|
|
|
|
[<i>ex</i>:SWDefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:SoftwarePlatform]
|
|
+--<i>ex</i>:name-----> "EPOC"
|
|
+--<i>ex</i>:version--> "2.0"
|
|
+--<i>ex</i>:vendor---> "Symbian"
|
|
|
|
[<i>ex</i>:UADefault]
|
|
|
|
|
+--<i>rdf</i>:type----> [<i>ex</i>:BrowserUA]
|
|
+--<i>ex</i>:name-----> "Mozilla"
|
|
+--<i>ex</i>:version--> "5.0"
|
|
+--<i>ex</i>:vendor---> "Symbian"
|
|
+--<i>ex</i>:htmlVersionsSupported--> { "3.2", "4.0" }</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>If a component referenced by <code><i>ccpp</i>:defaults</code> 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.</p>
|
|
|
|
<table summary="Figure 3-2b" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 3-2b: Resolving a CC/PP profile using
|
|
defaults</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[<i>ex</i>:MyProfile]
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalHardware]
|
|
| |
|
|
| +--<i>rdf</i>:type-------> [<i>ex</i>:HardwarePlatform]
|
|
| +--<i>ex</i>:displayWidth--> "640"
|
|
| +--<i>ex</i>:displayHeight-> "400"
|
|
| +--<i>ex</i>:cpu------> "PPC"
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalSoftware]
|
|
| |
|
|
| +--<i>rdf</i>:type-------> [<i>ex</i>:SoftwarePlatform]
|
|
| +--<i>ex</i>:name-----> "EPOC"
|
|
| +--<i>ex</i>:version--> "2.0"
|
|
| +--<i>ex</i>:vendor---> "Symbian"
|
|
|
|
|
+--<i>ccpp</i>:component--> [<i>ex</i>:TerminalBrowser]
|
|
|
|
|
------------
|
|
|
|
|
+--<i>rdf</i>:type-------> [<i>ex</i>:BrowserUA]
|
|
+--<i>ex</i>:htmlVersionsSupported--> { "2.0", "3.2", "4.0" }
|
|
+--<i>ex</i>:name-----> "Mozilla"
|
|
+--<i>ex</i>:version--> "5.0"
|
|
+--<i>ex</i>:vendor---> "Symbian"</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>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.</p>
|
|
|
|
<table summary="Figure 3-2c" border="1" width="0%" bgcolor="#CCFFCC">
|
|
<caption align="bottom">Figure 3-2c: CC/PP profile using inline defaults,
|
|
in XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 3-3" border="1" width="0%" bgcolor="#CCFFCC">
|
|
<caption align="bottom">Figure 3-3: CC/PP profile referencing externally
|
|
defined defaults, in XML</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Each external defaults resource is a separate RDF document referenced by a
|
|
URI.</p>
|
|
|
|
<blockquote>
|
|
<p><em><b>NOTE</b>:</em> A default document uses a
|
|
<code><<i>rdf</i>:Description></code> element as its root node. The
|
|
<code><<i>rdf</i>:Description></code> is named using an
|
|
<code><i>rdf</i>:about</code> whose value is a URI. This URI MUST
|
|
correspond to the value of the <code><i>rdf</i>:resource</code> XML
|
|
attribute in the <code><<i>ccpp</i>:defaults></code> 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.</p>
|
|
</blockquote>
|
|
|
|
<p>Examples of default documents referenced by the previous example are as
|
|
follows:</p>
|
|
|
|
<table summary="Figure 3-4" border="1" width="0%" bgcolor="#CCFFCC"
|
|
cellpadding="3">
|
|
<caption align="bottom">Figure 3-4: External HardwarePlatform default
|
|
values</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Document: http://example.com/HWDefault</b>
|
|
<pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p> </p>
|
|
|
|
<table summary="Figure 3-5" border="1" width="0%" bgcolor="#CCFFCC"
|
|
cellpadding="3">
|
|
<caption align="bottom">Figure 3-5: External SoftwarePlatform default
|
|
values</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Document: http://example.com/SWDefault</b>
|
|
<pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p> </p>
|
|
|
|
<table summary="Figure 3-6" border="1" width="0%" bgcolor="#CCFFCC"
|
|
cellpadding="3">
|
|
<caption align="bottom">Figure 3-6: External BrowseUA default
|
|
values</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Document: http://example.com/UADefault</b>
|
|
<pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h3><a name="DistinguishStructAttrib"></a>3.4 Distinguishing profile
|
|
structure from attributes</h3>
|
|
|
|
<p>CC/PP uses namespaces to distinguish the vocabulary associated with the
|
|
structure (e.g. <code><i>ccpp</i>:component</code>) from vocabularies
|
|
associated with applications (e.g. TerminalHardware, display).</p>
|
|
|
|
<p>In this example we use the namespace
|
|
"<code>http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#</code>",
|
|
associated with prefix "<code>prf:</code>", to describe properties that are
|
|
not defined in the CC/PP or RDF namespaces:</p>
|
|
|
|
<table summary="Figure 3-7" border="1" width="0%" bgcolor="#CCFFCC">
|
|
<caption align="bottom">Figure 3-7: XML serialization of CC/PP profile,
|
|
with namespaces</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre><?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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>All RDF resources that relate to the overall structure of CC/PP are
|
|
defined in the <i><code>ccpp</code></i><code>:</code> namespace, and have
|
|
associated schema properties that allow them to be distinguished from
|
|
attribute vocabulary or other RDF statements by a schema-aware processor.</p>
|
|
|
|
<h3><a name="RDFUsage"></a>3.5 Notes on RDF usage</h3>
|
|
|
|
<p>This specification uses "<code>rdf:about</code>" 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 "<code>rdf:about</code>" and "<code>rdf:ID</code>".</p>
|
|
|
|
<p>CC/PP allows "<code>rdf:ID</code>" attributes or "<code>rdf:about</code>"
|
|
attributes. However, the values of "<code>rdf:ID</code>" attributes represent
|
|
URIs which are relative to the base URI of the document <a
|
|
href="#34">[RDFFRAGMENT]</a>. When a document is moved to another location on
|
|
the web the meaning of the value of an "<code>rdf:ID</code>" 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 <a href="#36">[RDFXML]</a> that proposes that RDF should
|
|
support "<code>xml:base</code>" attributes. If this addition to RDF achieves
|
|
recommendation status, then it would be appropriate to use
|
|
"<code>rdf:ID</code>" attributes in conjunction with an
|
|
"<code>xml:base</code>" attribute instead of "<code>rdf:about</code>"
|
|
attributes. For now we recommend that CC/PP profiles SHOULD use
|
|
"<code>rdf:about</code>" and that the URIs of resources are fully
|
|
specified.</p>
|
|
|
|
<p>The component resources in a profile are instances of components
|
|
identified in the corresponding schema, which in turn MUST be subclasses of
|
|
<i><code>ccpp</code></i><code>:Component</code>. They may usefully be
|
|
identified as such, by means of the <i><code>rdf</code></i><code>:type</code>
|
|
property whose value matches the name of the component type in the schema.
|
|
(Sometimes this type indication MUST be present: see <a
|
|
href="#ProfileComponents">section 3.1, Components</a>.)</p>
|
|
|
|
<h3><a name="xtocid-58647528">3.6 RDF graph composition</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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. (<i><b>NOTE:</b></i>
|
|
implementations are <strong>not</strong> required to actually construct such
|
|
a document, just to interpret the RDF statements as they would from a single
|
|
document.)</p>
|
|
|
|
<p>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;
|
|
<i>viz.</i> <code><i>ccpp</i>:defaults</code>.</p>
|
|
|
|
<h2><a name="AttributeVocabularies"></a>4. Attribute vocabularies</h2>
|
|
|
|
<h3><a name="AttributeData"></a>4.1 Attribute data</h3>
|
|
|
|
<p>This section describes the basic data types and data structuring options
|
|
that are available for the values associated with a CCPP attribute.</p>
|
|
|
|
<p>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 <a
|
|
href="#ScopeOfDocument">1.1</a> and <a href="#Appendix_F">Appendix F</a>.)</p>
|
|
|
|
<h4><a name="SimpleAttribute">4.1.1 Simple CC/PP attribute data</a></h4>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<blockquote>
|
|
<p><i><b>NOTE</b></i>: 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.</p>
|
|
</blockquote>
|
|
|
|
<p>Where given, formal syntax expressions use the notation presented in
|
|
Section 6 of the XML specification <a href="#1">[XML]</a>.</p>
|
|
|
|
<h5><a name="xtocid-33666539">4.1.1.1 Strings</a></h5>
|
|
|
|
<p>The data type of a CC/PP attribute value may be defined to be a case
|
|
sensitive text string.</p>
|
|
|
|
<p>The RDF literal value is constrained to the lexical space defined in the
|
|
"string" XML schema datatype <a href="#14">[XMLSCHEMA-2]</a>. Any 'lang' tag
|
|
is ignored.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Some examples:</p>
|
|
<ul>
|
|
<li>Browser name: "Mozilla"</li>
|
|
<li>Browser version: "5.0"</li>
|
|
</ul>
|
|
|
|
<h5><a name="xtocid-33666543">4.1.1.2 Integer numbers</a></h5>
|
|
|
|
<p>The data type of a CC/PP attribute value may be defined to be an integer
|
|
number.</p>
|
|
|
|
<p>The RDF literal value is constrained to the lexical space defined in the
|
|
"int" XML schema datatype <a href="#14">[XMLSCHEMA-2]</a>. Any 'lang' tag is
|
|
ignored.</p>
|
|
|
|
<p>Integer numbers may be positive, zero or negative. They are represented by
|
|
a string containing a sequence of decimal digits, optionally preceded by a
|
|
'<tt>+</tt>' or '<tt>-</tt>' 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.</p>
|
|
|
|
<table summary="Figure 4-2" border="1" cellspacing="2" cellpadding="2"
|
|
width="44%">
|
|
<caption align="bottom">Figure 4-2: Syntax for integer numbers</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCCCFF">
|
|
<td width="100%"><pre>Signed-integer ::= ( '+' | '-' )? Unsigned-integer
|
|
|
|
|
|
Unsigned-integer ::= Digit (Digit)*</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Some examples:</p>
|
|
<ul>
|
|
<li>0</li>
|
|
<li>1</li>
|
|
<li>+0768</li>
|
|
<li>-256
|
|
<p><b><i>NOTE</i></b>: The choice of RECOMMENDED number range support was
|
|
based on support from Java and other programming languages widely used
|
|
for the Web.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h5><a name="xtocid-33666544">4.1.1.3 Rational numbers</a></h5>
|
|
|
|
<p>The data type of a CC/PP attribute value may be defined to be a rational
|
|
number.</p>
|
|
|
|
<p>In other words, the RDF literal value is constrained to the lexical space
|
|
defined below. Any 'lang' tag is ignored.</p>
|
|
|
|
<p>A rational number is expressed as a ratio of two integer numbers. Two
|
|
positive integers are separated by a '<tt>/</tt>', and optionally preceded by
|
|
a '<tt>+</tt>' or '<tt>-</tt>' sign.</p>
|
|
|
|
<p>It is RECOMMENDED that implementations generate and support numerators of
|
|
a rational number (the first number, before the '<tt>/</tt>') in the range 0
|
|
to 2147483647 (2^31-1), and denominators (after the '<tt>/</tt>') in the
|
|
range 1 to 2147483647.</p>
|
|
|
|
<table summary="Figure 4-3" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 4-3: Syntax for rational numbers</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCCCFF">
|
|
<td><pre>Rational-number ::= Signed-integer ( '/' Unsigned-integer )?</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>If the denominator is omitted, a value '<tt>1</tt>' is assumed; i.e. treat
|
|
value as an Integer.</p>
|
|
|
|
<p>Some examples:</p>
|
|
<ul>
|
|
<li>1/2</li>
|
|
<li>768/1024</li>
|
|
<li>-254/100</li>
|
|
<li>+2000/65536</li>
|
|
</ul>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE</i></b>: The rational number schema described above may be
|
|
defined in XML-Schema <a href="#12">[XMLSCHEMA-0]</a> as follows:</p>
|
|
|
|
<table summary="Figure 4-4" border="1" width="0%">
|
|
<caption align="bottom">Figure 4-4: Possible XML-Schema for rational
|
|
numbers</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCFFCC">
|
|
<td><pre><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></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>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.)</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="ComplexAttribute"></a>4.1.2 Complex CC/PP attribute data</h4>
|
|
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:
|
|
<ul>
|
|
<li>Set of values</li>
|
|
<li>Sequence of values</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<h5><a name="4.1.2.1">4.1.2.1 Set of values</a></h5>
|
|
A set consists of zero, one or more values, all different and whose order is
|
|
not significant.
|
|
|
|
<p>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.</p>
|
|
|
|
<p>A set is represented as an '<tt><i>rdf</i>:Bag</tt>', with each member of
|
|
the set corresponding to a property of that resource named
|
|
'<tt><i>rdf</i>:_1</tt>', '<tt><i>rdf</i>:_2</tt>', etc. This construct is
|
|
described in section 3 of the RDF Model and Syntax specification <a
|
|
href="#3">[RDF]</a>.</p>
|
|
|
|
<table summary="Figure 4-4" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 4-4: RDF representation of set values in
|
|
CC/PP</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[(Client-resource)]
|
|
+--(attributeName)--> [<rdf:Bag>]
|
|
+--rdf:_1--> (set-member-value-1)
|
|
+--rdf:_2--> (set-member-value-2)
|
|
:
|
|
+--rdf:_n--> (set-member-value-n)</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<blockquote>
|
|
<p><strong><em>NOTE</em></strong><b>:</b> The '<tt>rdf:Bag</tt>' construct
|
|
does not require that every contained value be unique. A set cannot contain
|
|
duplicate values, so every property of an '<tt>rdf:Bag</tt>' used to
|
|
represent a set must have a distinct value.</p>
|
|
</blockquote>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 4-5" border="1" cellspacing="2" cellpadding="2"
|
|
width="55%">
|
|
<caption align="bottom">Figure 4-5: Attribute with set value containing a
|
|
single member</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[(Client-resource)]
|
|
+--(attributeName)--> [<rdf:Bag>] --rdf:_1--> (set-member-value)</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Compare the above attribute value, which is a set containing one element,
|
|
with the following, which is a simple value:</p>
|
|
|
|
<table summary="Figure 4-6" border="1" cellspacing="2" cellpadding="2"
|
|
width="55%">
|
|
<caption align="bottom">Figure 4-6: Attribute with a simple value</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[(Client-resource)]
|
|
+--(attributeName)--> (attribute-value)</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h5><a name="4.1.2.2">4.1.2.2 Sequence of values</a></h5>
|
|
A sequence consists of zero, one or more values, whose order is significant
|
|
in some way.
|
|
|
|
<p>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.</p>
|
|
|
|
<p>A sequence is represented as an '<tt><i>rdf</i>:Seq</tt>', with each
|
|
member of the set corresponding to a property of that resource named
|
|
'<tt><i>rdf</i>:_1</tt>', '<tt><i>rdf</i>:_2</tt>', etc. This construct is
|
|
described in section 3 of the RDF Model and Syntax specification <a
|
|
href="#3">[RDF]</a>.</p>
|
|
|
|
<table summary="Figure 4-7" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure 4-7: RDF representation of sequence values
|
|
in CC/PP</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[(Client-resource)]
|
|
+--(attributeName)--> [<rdf:Seq>]
|
|
+--rdf:_1--> (sequence-value-1)
|
|
+--rdf:_2--> (sequence-value-2)
|
|
:
|
|
+--rdf:_n--> (sequence-value-n)</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>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:</p>
|
|
|
|
<table summary="Figure 4-8" border="1" cellspacing="2" cellpadding="2"
|
|
width="55%">
|
|
<caption align="bottom">Figure 4-8: Attribute with sequence value
|
|
containing a single member</caption>
|
|
<tbody>
|
|
<tr bgcolor="#FFFFCC">
|
|
<td><pre>[(Client-resource)]
|
|
+--(attributeName)--> [<rdf:Seq>] --rdf:_1--> (sequence-value)</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Compare the above attribute value, which is a sequence containing one
|
|
element, with the simple value as shown in figure 4-6 above.</p>
|
|
|
|
<h3><a name="xtocid-33666547">4.2 Attribute identifiers</a></h3>
|
|
|
|
<p>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:</p>
|
|
|
|
<blockquote>
|
|
<pre>http://www.w3.org/2002/11/08-ccpp-client#</pre>
|
|
</blockquote>
|
|
|
|
<p>and the core vocabulary name:</p>
|
|
|
|
<blockquote>
|
|
<pre>type</pre>
|
|
</blockquote>
|
|
|
|
<p>are combined to yield the attribute name URI reference:</p>
|
|
|
|
<blockquote>
|
|
<pre>http://www.w3.org/2002/11/08-ccpp-client#type</pre>
|
|
</blockquote>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Many extension vocabularies will be drawn from existing applications and
|
|
protocols; e.g. WAP UAProf, IETF media feature registrations, etc. <a
|
|
href="#Appendix_E">Appendix E</a> surveys some possible sources of additional
|
|
CC/PP vocabularies.</p>
|
|
|
|
<h3><a name="xtocid-33666548">4.3 RDF vocabulary schema</a></h3>
|
|
|
|
<p>Attribute names are defined, and associated with an XML namespace, using
|
|
an RDF schema.</p>
|
|
|
|
<p><a href="#Appendix_B">Appendix B</a> to this document contains an RDF
|
|
schema describing terms for use in CC/PP profiles. <a
|
|
href="#Appendix_C">Appendix C</a> contains an example Schema describing a
|
|
CC/PP vocabulary. <a href="#Appendix_D">Appendix D</a> contains
|
|
recommendations for creating a new vocabulary.</p>
|
|
|
|
<p>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.)</p>
|
|
|
|
<h2><a name="Conformance"></a>5. Conformance</h2>
|
|
|
|
<p>This section explains how to make a <a href="#ConformanceClaims">valid
|
|
claim</a> 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.</p>
|
|
|
|
<p>There are three classes of products of CC/PP:</p>
|
|
<ol>
|
|
<li>documents (e.g. a web resource)</li>
|
|
<li>producers (e.g. a web client)</li>
|
|
<li>consumers (e.g. a web server)</li>
|
|
</ol>
|
|
|
|
<h3><a name="ConformanceDocument"></a>5.1 CC/PP Document Conformance</h3>
|
|
|
|
<p>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:</p>
|
|
<ol>
|
|
<li>The document MUST be <a href="/RDF/Validator/">valid RDF</a> serialized
|
|
in XML, and be based on one or more vocabularies derived from the RDF
|
|
Schema in <a href="#Appendix_B">Appendix B</a>. See <a
|
|
href="#Introduction">section 1</a>.</li>
|
|
<li>The document MUST use valid syntax for namespace declarations. See <a
|
|
href="#ExtensibilityNamespaces">section 2.2</a>.</li>
|
|
<li>The profile element MUST contain one or more components. See <a
|
|
href="#CCPPProfileStructOverview">section 2.1</a>.</li>
|
|
<li>Each component in the profile MUST contain one or more attributes. See
|
|
<a href="#CCPPProfileStructOverview">section 2.1</a>.</li>
|
|
<li>The component names MAY be in rdf:about or rdf:ID attributes. See <a
|
|
href="#ProfileComponents">section 3.1</a>.</li>
|
|
<li>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 <a href="#ProfileComponents">section 3.1</a>.</li>
|
|
<li>Component names, component types, and attribute names must all refer to
|
|
different URIs within a profile. See <a href="#CCPPStructure">section
|
|
3</a>.</li>
|
|
<li>If a component type is given as an element name and as an rdf:type
|
|
element, they MUST refer to the same URI. See <a
|
|
href="#ProfileComponents">section 3.1</a>.</li>
|
|
<li>Default references MUST be valid URLs. See <a
|
|
href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>Defaults MAY be written as ccpp:defaults or ccpp:Defaults. See <a
|
|
href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>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 <a
|
|
href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>Component attributes MAY contain both a default value and a directly
|
|
applied value, with the directly applied value taking precedence. See <a
|
|
href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>Components MAY contain inline defaults. See <a
|
|
href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>Components MUST NOT contain both inline and referenced defaults. See <a
|
|
href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>Components MAY reference a default document which does not have an
|
|
rdf:type. See <a href="#ProfileDefaults">section 3.3</a>.</li>
|
|
<li>Attributes MAY have sets of values (Bags). See <a
|
|
href="#4.1.2.1">section 4.1.2.1</a>.</li>
|
|
<li>Attributes MAY have sequences of values (Seq). See <a
|
|
href="#4.1.2.2">section 4.1.2.2</a>.</li>
|
|
<li>Attributes MAY have string values. See <a
|
|
href="#xtocid-33666539">section 4.1.1.2</a>.</li>
|
|
<li>Attributes MAY have Integer number values. See <a
|
|
href="#xtocid-33666543">section 4.1.1.3</a>.</li>
|
|
<li>Attributes MAY have Rational number values. See <a
|
|
href="#xtocid-33666544">section 4.1.1.4</a>.</li>
|
|
<li>A component MUST NOT contain more than one attribute with the same
|
|
name. See <a href="#ProfileAttributes">section 3.2</a>.</li>
|
|
<li>Attributes of the same name MAY be in different components. See <a
|
|
href="#ProfileComponents">section 3.1</a>.</li>
|
|
<li>Profiles MAY use multiple namespaces for attributes. See <a
|
|
href="#ExtensibilityNamespaces">section 2.2</a>.<br>
|
|
</li>
|
|
</ol>
|
|
|
|
<h3><a name="ConformanceProducer"></a>5.2 CC/PP Producer Conformance</h3>
|
|
|
|
<p>A producer is CC/PP conformant when any CC/PP profile document generated
|
|
by the producer is a CC/PP conformant document.</p>
|
|
|
|
<h3><a name="ConformanceConsumer"></a>5.3 CC/PP Consumer Conformance</h3>
|
|
|
|
<p>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 <a
|
|
href="#Appendix_B">Appendix B</a> by CC/PP consumers is OPTIONAL (see <a
|
|
href="#xtocid-33666548">section 4.3</a>).</p>
|
|
|
|
<p>There are two categories of conformance for CC/PP consumers:</p>
|
|
<ol>
|
|
<li><b>Conformant</b>: a CC/PP consumer can claim to be a <i>"CC/PP 1.0
|
|
conformant consumer"</i> if it accepts any valid CC/PP profile and
|
|
extracts information from it.</li>
|
|
<li><b>Validating</b>: a CC/PP consumer can claim to be a <i>"CC/PP 1.0
|
|
conformant validating consumer"</i> if it is conformant and if it rejects
|
|
all invalid CC/PP profiles.</li>
|
|
</ol>
|
|
|
|
<div style="margin-left: 40px;">
|
|
<p><span style="font-weight: bold; font-style: italic;">NOTE</span>: A
|
|
consumer implementation may be configurable to act as either a conformant
|
|
consumer or a conformant validating consumer at different times.</p>
|
|
</div>
|
|
|
|
<h3><a name="ConformanceClaims"></a>5.4 Conformance Claims</h3>
|
|
|
|
<h4><a name="ConformanceClaimsValidity"></a>5.4.1 Validity</h4>
|
|
|
|
<p>A conformance claim is valid if it is <a
|
|
href="#ConformanceClaimsWellformed">well formed</a> and meets the appropriate
|
|
conformance criteria for the applicable product class as given above.</p>
|
|
|
|
<h4><a name="ConformanceClaimsWellformed"></a>5.4.2 Well-formed</h4>
|
|
|
|
<p>A conformance claim is well-formed if it includes the following
|
|
information:</p>
|
|
<ol>
|
|
<li>the date of the claim</li>
|
|
<li>the product class (document, producer, or consumer)</li>
|
|
<li>the consumer category (conformant or conformant validating) if
|
|
applicable</li>
|
|
<li>the title and dated URI of this document</li>
|
|
<li>the product name (identity), including a version, date, or other
|
|
identifier that uniquely identifies the product</li>
|
|
</ol>
|
|
|
|
<h2><a name="Acknowledgements"></a>6. Acknowledgments</h2>
|
|
|
|
<p>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:</p>
|
|
<ul>
|
|
<li>Mikael Nilsson, Ericsson Infotech</li>
|
|
<li>Ulrich Kauschke, T-Mobil</li>
|
|
<li>Ann Navarro, HTML Writers Guild</li>
|
|
<li>Brad Topol, IBM</li>
|
|
<li>Franklin Reynolds, Nokia</li>
|
|
<li>Graham Klyne, Baltimore Technologies</li>
|
|
<li>Noboru Iwayama, Fujitsu Laboratories LTD</li>
|
|
<li>Takashi Nishigaya, Fujitsu Laboratories LTD</li>
|
|
<li>Lalitha Surayanrayana, SBC Technology Resources</li>
|
|
<li>Hidetaka Ohto, W3C (through March 2002) / Panasonic</li>
|
|
<li>Simon McBride, DSTC Pty Ltd</li>
|
|
<li>Varuni Witana, DSTC Pty Ltd</li>
|
|
<li>Chris Woodrow, Information Architects</li>
|
|
<li>Johan Hjelm, Ericsson</li>
|
|
<li>Barry Briggs, Interleaf</li>
|
|
<li>Gerd Hoelzing, SAP</li>
|
|
<li>Ted Hardie, Equinix</li>
|
|
<li>Serge Rigori, Sun</li>
|
|
<li>Ted Wugofski, Phone.com</li>
|
|
<li>Kynn Bartlett, HTML Writers Guild</li>
|
|
<li>Sandeep Singhal, IBM</li>
|
|
<li>Thorsten Kassing, T-Mobil</li>
|
|
<li>Larry Masinter, Adobe</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The following members of the DI WG also provided assistance in completing
|
|
the specification: Stephane Boyera, Roger Gimson, Kazuhiro Kitagawa, Andreas
|
|
Schade.</p>
|
|
|
|
<h2><a name="xtocid-33666550">7. References</a></h2>
|
|
|
|
<h3><a name="norm_refs">7.1.</a> Normative References</h3>
|
|
<dl>
|
|
<dt><a name="1"></a>[XML]</dt>
|
|
<dd>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: <a
|
|
href="/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</a>
|
|
As amended by: XML 1.0 Second Edition Specification Errata; <a
|
|
href="/XML/xml-V10-2e-errata">http://www.w3.org/XML/xml-V10-2e-errata</a>,
|
|
specifically <a
|
|
href="/XML/xml-V10-2e-errata#E26">http://www.w3.org/XML/xml-V10-2e-errata#E26</a>.</dd>
|
|
<dt><a name="2"></a>[XMLNAMESPACES]</dt>
|
|
<dd>Namespaces in XML; Tim Bray, Dave Hollander, Andrew Layman; World
|
|
Wide Web Consortium Recommendation 14 January 1999: <a
|
|
href="/TR/1999/REC-xml-names-19990114/">http://www.w3.org/TR/1999/REC-xml-names-19990114/</a></dd>
|
|
<dt><a name="3"></a>[RDF]</dt>
|
|
<dd>Resource Description Framework (RDF) Model and Syntax Specification;
|
|
Ora Lassila, Ralph Swick; World Wide Web Consortium Recommendation 22
|
|
February 1999: <a
|
|
href="/TR/1999/REC-rdf-syntax-19990222/">http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/</a></dd>
|
|
<dt><a name="4"></a>[RDFSCHEMA]</dt>
|
|
<dd>Resource Description Framework (RDF) Schema Specification; Dan
|
|
Brickley, R. V. Guha; World Wide Web Consortium Candidate
|
|
Recommendation 27 March 2000: <a
|
|
href="/TR/2000/CR-rdf-schema-20000327/">http://www.w3.org/TR/2000/CR-rdf-schema-20000327/</a></dd>
|
|
<dt><a name="36"></a>[RDFXML]</dt>
|
|
<dd>RDF/XML Syntax Specification; Dave Beckett; World Wide Web Consortium
|
|
Working Draft: <a
|
|
href="/TR/2003/WD-rdf-syntax-grammar-20030123/">http://www.w3.org/TR/2003/WD-rdf-syntax-grammar-20030123/</a></dd>
|
|
</dl>
|
|
|
|
<h3><a name="inform_refs">7.2.</a> Informative References</h3>
|
|
<dl>
|
|
<dt><a name="5"></a>[RFC2506]</dt>
|
|
<dd>RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A.
|
|
Mutz, T. Hardie; IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2506.txt">ftp://ftp.isi.edu/in-notes/rfc2506.txt</a></dd>
|
|
<dt><a name="6"></a>[RFC2533]</dt>
|
|
<dd>RFC 2533: A Syntax for Describing Media Feature Sets; G. Klyne; IETF
|
|
Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2533.txt">ftp://ftp.isi.edu/in-notes/rfc2533.txt</a></dd>
|
|
<dt><a name="7"></a>[CONNEGMATCH]</dt>
|
|
<dd>A revised media feature set matching algorithm; G. Klyne;
|
|
Internet-Draft, work in progress: <a
|
|
href="http://lists.w3.org/Archives/Public/www-archive/2003Apr/0047.html">
|
|
draft-klyne-conneg-feature-match-02.txt</a></dd>
|
|
<dt><a name="8"></a>[RFC2534]</dt>
|
|
<dd>RFC 2534: Media Features for Display, Print, and Fax; L. Masinter, D.
|
|
Wing, A. Mutz, K. Holtman; IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2534.txt">ftp://ftp.isi.edu/in-notes/rfc2534.txt</a></dd>
|
|
<dt><a name="9"></a>[UAPROF]</dt>
|
|
<dd>WAP-174: <a
|
|
href="http://www.wapforum.org/what/technical/SPEC-UAProf-19991110.pdf">UAProf
|
|
User Agent Profiling Specification (1999)</a> as amended by WAP-174_100
|
|
User Agent Profiling Specification Information Note (2001) Wireless
|
|
Application Protocol Forum available at <a
|
|
href="http://www.wapforum.org/what/technical_1_2.htm">http://www.wapforum.org/what/technical_1_2.htm</a>
|
|
<p>Also see WAP-248-UAProf Version 20-Oct-2001 available at <a
|
|
href="http://www.wapforum.org/what/technical.htm">http://www.wapforum.org/what/technical.htm</a></p>
|
|
</dd>
|
|
<dt><a name="11"></a>[DATASTRUCTURE]</dt>
|
|
<dd>Notes on Data Structuring; C. A. R. Hoare; in Structured Programming,
|
|
Academic Press, 1972. ISBN 0-12-2000556-2.</dd>
|
|
<dt><a name="12"></a>[XMLSCHEMA-0]</dt>
|
|
<dd>XML Schema. Part 0: Primer; David C. Fallside; World Wide Web
|
|
Consortium Recommendation 2 May 2001: <a
|
|
href="/TR/2001/REC-xmlschema-0-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/</a></dd>
|
|
<dt><a name="13"></a>[XMLSCHEMA-1]</dt>
|
|
<dd>XML Schema. Part 1: Structures; Henry S. Thompson, David Beech,
|
|
Murray Maloney, Noah Mendelsohn; World Wide Web Consortium
|
|
Recommendation 2 May 2001: <a
|
|
href="/TR/2001/REC-xmlschema-1-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/</a></dd>
|
|
<dt><a name="14"></a>[XMLSCHEMA-2]</dt>
|
|
<dd>XML Schema. Part 2: Datatypes; Paul V. Biron, Ashok Malhotra; World
|
|
Wide Web Consortium Recommendation 2 May 2001: <a
|
|
href="/TR/2001/REC-xmlschema-2-20010502/">http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/</a></dd>
|
|
<dt><a name="15"></a>[SEMANTICTOOLBOX]</dt>
|
|
<dd>The Semantic Toolbox: Building Semantics on top of XML-RDF; Tim
|
|
Berners-Lee; <a
|
|
href="/DesignIssues/Toolbox.html">http://www.w3.org/DesignIssues/Toolbox.html</a></dd>
|
|
<dt><a name="16"></a>[RFC2531]</dt>
|
|
<dd>RFC 2531: Content Feature Schema for Internet Fax; G. Klyne, L.
|
|
McIntyre; IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2531.txt">ftp://ftp.isi.edu/in-notes/rfc2531.txt</a></dd>
|
|
<dt><a name="17"></a>[TIFF]</dt>
|
|
<dd>TIFF (Tagged Image File Format) 6.0 Specification; Adobe Systems
|
|
Inc.; <a
|
|
href="http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf">http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf</a></dd>
|
|
<dt><a name="18"></a>[RFC2301]</dt>
|
|
<dd>RFC 2301: File Format for Internet Fax; L. McIntyre, S. Zilles, R.
|
|
Buckley, D. Venable, G. Parsons, J. Rafferty; IETF Request for
|
|
Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2301.txt">ftp://ftp.isi.edu/in-notes/rfc2301.txt</a></dd>
|
|
<dt><a name="19"></a>[MULTIMEDIA]</dt>
|
|
<dd>Multimedia Programming Interface and Data Specifications 1.0
|
|
(contains WAVE file format); IBM Corporation and Microsoft Corporation;
|
|
<riffspec.txt></dd>
|
|
<dt><a name="20"></a>[RFC2361]</dt>
|
|
<dd>RFC 2361: WAVE and AVI Codec Registries; E. Fleischman; IETF Request
|
|
for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2361.txt">ftp://ftp.isi.edu/in-notes/rfc2361.txt</a></dd>
|
|
<dt><a name="21"></a>[MPEG]</dt>
|
|
<dd>MPEG-4 Overview - (V.14 - Geneva Version), ISO/IEC JTC1/SC29/WG11
|
|
N3444 Rob Koenen Overview of the MPEG-4 Standard: <a
|
|
href="http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm"></a></dd>
|
|
<dt><a name="22"></a>[PWG]</dt>
|
|
<dd>Printer Working Group; <a
|
|
href="http://www.pwg.org/">http://www.pwg.org</a></dd>
|
|
<dt><a name="23"></a>[RFC2566]</dt>
|
|
<dd>RFC 2566: Internet Printing Protocol/1.0: Model and Semantics; R.
|
|
deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell; IETF Request
|
|
for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2566.txt</a></dd>
|
|
<dt><a name="24"></a>[SALUTATION]</dt>
|
|
<dd>Salutation Consortium Specification; <a
|
|
href="http://www.salutation.org/">http://www.salutation.org/</a></dd>
|
|
<dt><a name="25"></a>[RFC2119]</dt>
|
|
<dd>RFC 2119: Key words for use in RFCs to Indicate Requirement Levels;
|
|
S. Bradner; IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">ftp://ftp.isi.edu/in-notes/rfc2119.txt</a>.</dd>
|
|
<dt><a name="26"></a>[MPEG-7]</dt>
|
|
<dd>MPEG-7 Overview (version 8.0), ISO/IEC JTC1/SC29/WG11 N3445 Jos矍.
|
|
Mart쭥z (UPM-GTI, ES) Overview of the MPEG-7 Standard: <a
|
|
href="http://www.chiariglione.org/mpeg/standards/mpeg-7/mpeg-7.htm">http://mpeg.telecomitalialab.com/standards/mpeg-7/mpeg-7.htm</a></dd>
|
|
<dt><a name="27"></a>[RFC2277]</dt>
|
|
<dd>RFC 2277: IETF Policy on Character Sets and Languages; H. Alvestrand;
|
|
IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2277.txt</a></dd>
|
|
<dt><a name="28"></a>[RFC2396]</dt>
|
|
<dd>RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax; T.
|
|
Berners-Lee, R. Fielding, L. Masinter; IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2396.txt</a></dd>
|
|
<dt><a name="29"></a>[RFC2278]</dt>
|
|
<dd>RFC 2278: IANA Charset Registration Procedures; N. Freed, J. Postel;
|
|
IETF Request for Comments: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2566.txt">ftp://ftp.isi.edu/in-notes/rfc2278.txt</a></dd>
|
|
<dt><a name="30"></a>[CCPPARCH]</dt>
|
|
<dd>Composite Capabilities/Preference Profiles: Requirements and
|
|
Architecture; Mikael Nilsson, Johan Hjelm, Hidetaka Ohto; World Wide
|
|
Web Consortium Working Draft 21 July 2000: <a
|
|
href="/TR/2000/WD-CCPP-ra-20000721/">http://www.w3.org/TR/2000/WD-CCPP-ra-20000721/</a></dd>
|
|
<dt><a name="31"></a>[RFC2616]</dt>
|
|
<dd>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: <a
|
|
href="ftp://ftp.isi.edu/in-notes/rfc2616.txt">ftp://ftp.isi.edu/in-notes/rfc2616.txt</a></dd>
|
|
<dt><a name="32"></a>[CONCEPTUAL]</dt>
|
|
<dd>Conceptual Structures: Information Processing in Mind and Machine;
|
|
John F. Sowa; Addison Wesley, Reading MA, 1984.</dd>
|
|
<dt><a name="33"></a>[KNOWLEDGE]</dt>
|
|
<dd>Knowledge Representation; John F. Sowa; Brooks/Cole, 2000. ISBN:
|
|
0-534-94965-7</dd>
|
|
<dt><a name="34"></a>[RDFFRAGMENT]</dt>
|
|
<dd>Re: How to address RDF fragment; Ralph R Swick; Message to World Wide
|
|
Web Consortium RDF-comments mailing list: <a
|
|
href="http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html">
|
|
http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html</a>.</dd>
|
|
<dt><a name="35"></a>[CCPPEX]</dt>
|
|
<dd>CC/PP exchange protocol;Hidetaka Ohto, Johan Hjelm; World Wide Web
|
|
Consortium Note 24 June 1999: <a
|
|
href="/1999/06/NOTE-CCPPexchange-19990624">http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624</a></dd>
|
|
<dt><a name="37"></a>[WAI]</dt>
|
|
<dd>Web Content Accessibility Guidelines 2.0; Wendy Chisholm, Jason
|
|
White, Gregg Vanderheiden; World Wide Web Consortium Working Draft 22
|
|
August 2002: <a
|
|
href="/TR/2002/WD-WCAG20-20020822/">http://www.w3.org/TR/2002/WD-WCAG20-20020822/</a></dd>
|
|
</dl>
|
|
<dl>
|
|
<dt><a name="rdfprimer"></a>[RDFPRIMER]</dt>
|
|
<dd>RDF Primer; Frank Manola, Eric Miller; World Wide Web Consortium
|
|
Working Draft 23 January 2003: <a
|
|
href="/TR/2003/WD-rdf-primer-20030123/">http://www.w3.org/TR/2003/WD-rdf-primer-20030123/</a></dd>
|
|
</dl>
|
|
|
|
<h2><a name="Appendix_A"></a>Appendix A: Terminology and abbreviations</h2>
|
|
|
|
<h3><a name="Terminology"></a>A.1 Terminology</h3>
|
|
|
|
<p>This appendix is INFORMATIVE.</p>
|
|
<dl>
|
|
<dt>Attribute, or CC/PP attribute</dt>
|
|
<dd>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.
|
|
<b><i>NOTE</i></b>: 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.</dd>
|
|
<dt>CC/PP Processor</dt>
|
|
<dd>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.</dd>
|
|
<dt>CC/PP Repository</dt>
|
|
<dd>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.</dd>
|
|
<dt>Cacheable</dt>
|
|
<dd>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.</dd>
|
|
<dt>Cache</dt>
|
|
<dd>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.</dd>
|
|
<dt>Capability</dt>
|
|
<dd>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".</dd>
|
|
<dt>Client</dt>
|
|
<dd>An entity that is the original compositor of a CC/PP profile.</dd>
|
|
<dt>Confidentiality</dt>
|
|
<dd>Protecting the content of a message from unauthorized disclosure.</dd>
|
|
<dt>Content Generation</dt>
|
|
<dd>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.</dd>
|
|
<dt>Content Negotiation</dt>
|
|
<dd>The mechanism for selecting the appropriate representation when
|
|
servicing a request. The representation of entities in any response can
|
|
be negotiated (including error responses).</dd>
|
|
<dt>Content Selection</dt>
|
|
<dd>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.</dd>
|
|
<dt>Content Provider</dt>
|
|
<dd>A server that originates content in response to a request.</dd>
|
|
<dt>Data Resource</dt>
|
|
<dd>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.</dd>
|
|
<dt>Document</dt>
|
|
<dd>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".</dd>
|
|
<dt>Document Profile</dt>
|
|
<dd>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.</dd>
|
|
<dt>Dynamic Content</dt>
|
|
<dd>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)</dd>
|
|
<dt>Feature</dt>
|
|
<dd>Functional property of a device or entity.</dd>
|
|
<dt>Gateway</dt>
|
|
<dd>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.</dd>
|
|
<dt>Hint</dt>
|
|
<dd>A suggestion or preference for a particular option. While this option
|
|
is strongly recommended, its use is not required.</dd>
|
|
<dt>Machine Understandable</dt>
|
|
<dd>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.</dd>
|
|
<dt>Namespace</dt>
|
|
<dd>A qualifier added to an XML tag to ensure uniqueness among XML
|
|
elements.</dd>
|
|
<dt>Negotiate Content</dt>
|
|
<dd>Message content that has been selected by content negotiation.</dd>
|
|
<dt>Negotiation Metadata</dt>
|
|
<dd>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.</dd>
|
|
<dt>Non-variant Content</dt>
|
|
<dd>When the form/format of the content being sent does not depend on
|
|
receiver's capabilities and/or preferences</dd>
|
|
<dt>Origin Server</dt>
|
|
<dd>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.</dd>
|
|
<dt>Preference</dt>
|
|
<dd>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.</dd>
|
|
<dt>Privacy</dt>
|
|
<dd>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.</dd>
|
|
<dt>Profile</dt>
|
|
<dd>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.</dd>
|
|
<dt>Proxy</dt>
|
|
<dd>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.</dd>
|
|
<dt>RDF Resource</dt>
|
|
<dd>An object or element being described by RDF expressions is a
|
|
resource. An RDF resource is typically identified by a URI.</dd>
|
|
<dt>Receiver</dt>
|
|
<dd>A system component (device or program) which receives a message.</dd>
|
|
<dt>Schema, RDF Schema</dt>
|
|
<dd>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.</dd>
|
|
<dt>Security</dt>
|
|
<dd>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.</dd>
|
|
<dt>Sender</dt>
|
|
<dd>A system component (device or program) which transmits a message.</dd>
|
|
<dt>User</dt>
|
|
<dd>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.</dd>
|
|
<dt>User agent</dt>
|
|
<dd>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.</dd>
|
|
<dt>User agent profile</dt>
|
|
<dd>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.</dd>
|
|
<dt>Variant</dt>
|
|
<dd>One of several possible representations of a data resource.</dd>
|
|
<dt>Variant Content</dt>
|
|
<dd>When the form/format of the content being sent depends on receiver's
|
|
capabilities and/or preferences</dd>
|
|
<dt>Vocabulary</dt>
|
|
<dd>A collection of attributes that adequately describe the CC/PP. A
|
|
vocabulary is associated with a schema.</dd>
|
|
</dl>
|
|
|
|
<h3><a name="Abbreviations">A.2 Abbreviations</a></h3>
|
|
|
|
<table summary="Abbreviations">
|
|
<tbody>
|
|
<tr>
|
|
<th>CC/PP</th>
|
|
<td>Composite Capabilities/Preferences Profile</td>
|
|
</tr>
|
|
<tr>
|
|
<th>CC/PPex</th>
|
|
<td>CC/PP Exchange Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>CONNEG</th>
|
|
<td>Content Negotiation Working Group in the IETF</td>
|
|
</tr>
|
|
<tr>
|
|
<th>ER</th>
|
|
<td>Entity-Relationship</td>
|
|
</tr>
|
|
<tr>
|
|
<th>HTML</th>
|
|
<td>HyperText Markup Language</td>
|
|
</tr>
|
|
<tr>
|
|
<th>HTTP</th>
|
|
<td>HyperText Transfer Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>HTTPex</th>
|
|
<td>HTTP Extension Framework</td>
|
|
</tr>
|
|
<tr>
|
|
<th>IANA</th>
|
|
<td>Internet Assigned Numbers Authority</td>
|
|
</tr>
|
|
<tr>
|
|
<th>IETF</th>
|
|
<td>Internet Engineering Task Force</td>
|
|
</tr>
|
|
<tr>
|
|
<th>IOTP</th>
|
|
<td>Internet Open Trading Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>LDAP</th>
|
|
<td>Lightweight Directory Access Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>OTA</th>
|
|
<td>Over The Air, i.e. in the radio network</td>
|
|
</tr>
|
|
<tr>
|
|
<th>RDF</th>
|
|
<td>Resource Description Framework</td>
|
|
</tr>
|
|
<tr>
|
|
<th>RFC</th>
|
|
<td>Request For Comments</td>
|
|
</tr>
|
|
<tr>
|
|
<th>TBD</th>
|
|
<td>To Be Determined</td>
|
|
</tr>
|
|
<tr>
|
|
<th>TCP/IP</th>
|
|
<td>Transmission Control Protocol/Internet Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>UAProf</th>
|
|
<td>WAP User Agent Profile</td>
|
|
</tr>
|
|
<tr>
|
|
<th>W3C</th>
|
|
<td>World Wide Web Consortium</td>
|
|
</tr>
|
|
<tr>
|
|
<th>WAP</th>
|
|
<td>Wireless Application Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>WBXML</th>
|
|
<td>WAP Binary XML</td>
|
|
</tr>
|
|
<tr>
|
|
<th>WML</th>
|
|
<td>Wireless Markup Language</td>
|
|
</tr>
|
|
<tr>
|
|
<th>WSP</th>
|
|
<td>Wireless Session Protocol</td>
|
|
</tr>
|
|
<tr>
|
|
<th>XHTML</th>
|
|
<td>Extensible HyperText Markup Language</td>
|
|
</tr>
|
|
<tr>
|
|
<th>XSL</th>
|
|
<td>Extensible Stylesheet Language</td>
|
|
</tr>
|
|
<tr>
|
|
<th>XML</th>
|
|
<td>Extensible Markup Language</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2><a name="Appendix_B"></a>Appendix B: RDF schema for structure</h2>
|
|
|
|
<p>This appendix is NORMATIVE, but support by CC/PP processors is
|
|
OPTIONAL.</p>
|
|
|
|
<h3><a name="xtocid-33666555">B.1 Summary of CC/PP class hierarchy</a></h3>
|
|
|
|
<table summary="Figure B-1" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure B-1: CC/PP class hierarchy</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCCCFF">
|
|
<td><pre>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}</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h3><a name="xtocid-33666556">B.2 Summary of CC/PP properties</a></h3>
|
|
|
|
<h4><a name="xtocid-33666557">Structural properties (instances of</a>
|
|
<tt>ccpp:Structure</tt>)</h4>
|
|
|
|
<table summary="Figure B-2" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure B-2: CC/PP structural properties</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCCCFF">
|
|
<td><pre>ccpp:component Domain=ccpp:Profile, Range=ccpp:Component
|
|
ccpp:defaults Domain=ccpp:Component, Range=ccpp:Component</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h3><a name="xtocid-33666558">B.3 RDF Schema</a></h3>
|
|
|
|
<h4><a name="xtocid-33666559">CC/PP core and class structure:</a></h4>
|
|
|
|
<p>(Schema URI: <tt><a
|
|
href="/2002/11/08-ccpp-schema">http://www.w3.org/2002/11/08-ccpp-schema</a></tt>)</p>
|
|
|
|
<table summary="Figure B-3" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure B-3: RDF schema for CC/PP classes and core
|
|
properties</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCFFCC">
|
|
<td><pre><?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;Literal'/>
|
|
<rdfs:comment xml:lang="en">
|
|
This is the class of RDF Literals that represent CC/PP
|
|
attribute rational number values.
|
|
</rdfs:comment>
|
|
</rdfs:Class>
|
|
|
|
<rdfs:Class rdf:about='&ns-ccpp;Property'>
|
|
<rdfs:label xml:lang="en">CC/PP Property</rdfs:label>
|
|
<rdfs:subClassOf rdf:resource='&ns-rdf;Property'/>
|
|
<rdfs:comment xml:lang="en">
|
|
ccpp:Property is the super-class for ccpp:Structure and
|
|
ccpp:Attribute. Therefore all property arcs that are not part
|
|
of the core RDF namespace and constitute parts of a CC/PP
|
|
profile are defined as subclasses of ccpp:Property. This
|
|
allows schema-validating environments with language mixing to
|
|
isolate the CC/PP elements of an RDF graph rooted in some
|
|
given resource from other attributes of that resource.
|
|
</rdfs:comment>
|
|
</rdfs:Class>
|
|
|
|
<rdfs:Class rdf:about='&ns-ccpp;Structure'>
|
|
<rdfs:label xml:lang="en">CC/PP structural property</rdfs:label>
|
|
<rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/>
|
|
<rdfs:comment xml:lang="en">
|
|
All properties that are structural elements of a CC/PP profile
|
|
are defined as instances of ccpp:Structure. This allows
|
|
structural combining elements of a profile to be distinguished
|
|
from attributes in a schema-aware environment.
|
|
</rdfs:comment>
|
|
</rdfs:Class>
|
|
|
|
<rdfs:Class rdf:about='&ns-ccpp;Attribute'>
|
|
<rdfs:label xml:lang="en">CC/PP Attribute</rdfs:label>
|
|
<rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/>
|
|
<rdfs:comment xml:lang="en">
|
|
All properties that describe client capabilities or preferences
|
|
in a CC/PP profile should be defined as instances of
|
|
ccpp:Attribute. This allows structural combining elements
|
|
of a profile to be distinguished from client features in a
|
|
schema-validating environment.
|
|
</rdfs:comment>
|
|
</rdfs:Class>
|
|
|
|
|
|
<!-- CC/PP structural property definitions -->
|
|
<!-- Basic client profile description -->
|
|
|
|
<ccpp:Structure rdf:about='&ns-ccpp;component'>
|
|
<rdfs:label xml:lang="en">CC/PP component property</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Client-profile'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:comment xml:lang="en">
|
|
Indicates a component of a top-level client profile.
|
|
</rdfs:comment>
|
|
</ccpp:Structure>
|
|
|
|
<ccpp:Structure rdf:about='&ns-ccpp;defaults'>
|
|
<rdfs:label xml:lang="en">CC/PP default properties</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:comment xml:lang="en">
|
|
This property indicates a Component that contains default
|
|
properties for some other component. That is, any attributes
|
|
that are not found in the subject resource but are present in
|
|
the object resource may be incorporated from the object into
|
|
the resulting CC/PP profile.
|
|
</rdfs:comment>
|
|
</ccpp:Structure>
|
|
|
|
<ccpp:Structure rdf:about='&ns-ccpp;Defaults'>
|
|
<rdfs:label xml:lang="en">CC/PP default properties</rdfs:label>
|
|
<rdfs:subPropertyOf rdf:resource='&ns-ccpp;defaults'/>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:comment xml:lang="en">
|
|
Same as 'defaults'.
|
|
Defined as sub-property for backwards compatibility with UAProf
|
|
|
|
Use of this is deprecated: use 'defaults' instead.
|
|
</rdfs:comment>
|
|
</ccpp:Structure>
|
|
</rdf:RDF></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2><a name="Appendix_C"></a>Appendix C: CC/PP attribute vocabulary for print
|
|
and display</h2>
|
|
|
|
<p>The appendix is OPTIONAL and INFORMATIVE.</p>
|
|
|
|
<p>Designers of CC/PP applications who need to describe such features are
|
|
encouraged to use this vocabulary rather than define new terms. This
|
|
vocabulary is based in part on work done in the IETF media feature
|
|
registration (CONNEG) Working Group <a href="#8">[RFC2534]</a>.</p>
|
|
|
|
<p>The client attribute names defined below may be used to identify some
|
|
common features associated with client devices that print or display visual
|
|
information, such as text or graphics. They are described using XML namespace
|
|
local parts, which are further qualified by the XML namespace identifier
|
|
<tt><a
|
|
href="/2002/11/08-ccpp-client">http://www.w3.org/2002/11/08-ccpp-client</a></tt>.
|
|
(These attributes apply to presented capabilities of the client rather than
|
|
to a specific internal component or aspect of a client system.)</p>
|
|
<dl>
|
|
<dt><i>deviceIdentifier</i>:</dt>
|
|
<dd>(Value data type: String) A URI that serves as an identifier of the
|
|
client device or user agent type.</dd>
|
|
<dt><i>type</i>:</dt>
|
|
<dd>(Value data type: set of Strings) A MIME content type that can be
|
|
accepted and presented by a client. Similar in principle to the HTTP
|
|
'accept:' header, but specifying a single MIME content-type, without
|
|
associated content-type parameters. Multiple accepted content-types can
|
|
be described by a value that is a set of content-type string values.
|
|
Where needed, content-type parameters can be expressed by additional
|
|
CC/PP attributes.</dd>
|
|
<dt><i>schema</i>:</dt>
|
|
<dd>(Value data type: set of Strings) A URI that identifies a schema that
|
|
is recognized by the client. The schema may be an XML DTD <a
|
|
href="#1">[XML]</a>, XML Schema <a href="#13">[XMLSCHEMA-1]</a>, RDF
|
|
Schema <a href="#4">[RDFSCHEMA]</a> or any other applicable document
|
|
structure that can be identified by a URI. A <i>Schema</i> value
|
|
refines any acceptable document type indicated by the <i>Type</i>
|
|
attribute, but its meaning must not depend on the value of <i>Type</i>.
|
|
Typically, this will be used to indicate specific XML DTDs or schema
|
|
that are recognized within <tt>text/xml</tt> or
|
|
<tt>application/xml</tt> document types.</dd>
|
|
<dt><i><font color="black">cha</font>rW<font
|
|
color="black">idth</font></i>:</dt>
|
|
<dd>(Value data type: Integer) For a text display device (type="text/*"),
|
|
the width of the character display. For non-proportional font displays,
|
|
the number of display cells. For non-proportional font displays as
|
|
typically used in East Asia, the number of half-width display cells
|
|
(ideographic characters and other full-width characters typically
|
|
occupy two display cells). For proportional font displays, the width of
|
|
the display in ens (where an en is the typographical unit that is the
|
|
width of an en-dash/letter 'n').</dd>
|
|
<dt><i>charHeight</i>:</dt>
|
|
<dd>(Value data type: Integer) For a text display device
|
|
(<tt>type="text/*"</tt>), the number of lines of text that can be
|
|
displayed (i.e. the display height in characters).</dd>
|
|
<dt><i>charset</i>:</dt>
|
|
<dd>(Value data type: set of Strings, per <a href="#29">[RFC2278]</a>)
|
|
For a text handling device, a character encoding that can be processed
|
|
(values per MIME 'charset' parameter on content-type
|
|
<tt>"text/*"</tt>). <i><b>NOTE:</b></i> the term "charset" is a
|
|
historical misnomer, and does not necessarily indicate a repertoire of
|
|
characters that can be displayed, just an encoding. In some cases,
|
|
though, the encoding may imply a repertoire.</dd>
|
|
<dt><i>pix-x</i>:</dt>
|
|
<dd>(Value data type: Integer) For an image display device
|
|
(<tt>type="image/*"</tt>), the number of horizontal pixels that can be
|
|
displayed.</dd>
|
|
<dt><i>pix-y</i>:</dt>
|
|
<dd>(Value data type: Integer) For an image display device
|
|
(<tt>type="image/*"</tt>), the number of vertical pixels that can be
|
|
displayed.</dd>
|
|
<dt><i>color</i>:</dt>
|
|
<dd>(Value data type: String, per <a href="#8">[RFC2534]</a>) For text
|
|
and image display devices, an indication of the color capabilities (per
|
|
RFC 2534 <a href="#8">[RFC2534]</a>, possible values are
|
|
"<tt>binary</tt>", "<tt>grey</tt>", "<tt>limited</tt>",
|
|
"<tt>mapped</tt>" and "<tt>full</tt>").
|
|
<strong><em>NOTE</em></strong><b>:</b> the <i>color</i> attribute
|
|
provides a very coarse indication of color capabilities, sufficient for
|
|
a range of simple applications, and may be refined by additional
|
|
attributes where capabilities need to be described in greater
|
|
detail.</dd>
|
|
</dl>
|
|
|
|
<h4><a name="xtocid-33666562">Client attribute properties (instances of</a>
|
|
<tt>ccpp:Attribute</tt>)</h4>
|
|
|
|
<table summary="Figure C-1" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure C-1: CC/PP client vocabulary
|
|
properties</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCCCFF">
|
|
<td><pre>ccpp-client:deviceIdentifier Domain=ccpp:Component, Range=ccpp:string
|
|
ccpp-client:type Domain=ccpp:Component, Range=rdf:Bag
|
|
ccpp-client:schema Domain=ccpp:Component, Range=ccpp:string
|
|
ccpp-client:charWidth Domain=ccpp:Component, Range=ccpp:integer
|
|
ccpp-client:charHeight Domain=ccpp:Component, Range=ccpp:integer
|
|
ccpp-client:charset Domain=ccpp:Component, Range=rdf:Bag
|
|
ccpp-client:pix-x Domain=ccpp:Component, Range=ccpp:integer
|
|
ccpp-client:pix-y Domain=ccpp:Component, Range=ccpp:integer
|
|
ccpp-client:color Domain=ccpp:Component, Range=ccpp:string</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h4><a name="xtocid-62790564">Schema for client vocabulary</a></h4>
|
|
|
|
<p>(Schema URI: <tt><a
|
|
href="/2002/11/08-ccpp-client">http://www.w3.org/2002/11/08-ccpp-client</a></tt>)</p>
|
|
|
|
<table summary="Figure C-2" border="1" cellspacing="2" cellpadding="2">
|
|
<caption align="bottom">Figure C-2: RDF schema for client
|
|
vocabulary</caption>
|
|
<tbody>
|
|
<tr bgcolor="#CCFFCC">
|
|
<td><pre><?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#'>
|
|
<!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-ccpp-client#'>
|
|
]>
|
|
|
|
<rdf:RDF
|
|
xmlns:rdf = '&ns-rdf;'
|
|
xmlns:rdfs = '&ns-rdfs;'
|
|
xmlns:ccpp = '&ns-ccpp;'
|
|
xmlns:ccpp-client = '&ns-ccpp-client;'>
|
|
|
|
<!-- CC/PP attribute property definitions -->
|
|
|
|
<!-- These properties represent some common vocabulary that is -->
|
|
<!-- available for use by applications that need to indicate -->
|
|
<!-- the common features indicated by these attributes. They -->
|
|
<!-- serve as an example of how a new attribute vocabulary can -->
|
|
<!-- be defined for use in a CC/PP profile. -->
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;deviceIdentifier'>
|
|
<rdfs:label xml:lang="en">Client device identifier</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;string'/>
|
|
<rdfs:comment xml:lang="en">
|
|
A URI that identifies the type of client device or user agent.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;type'>
|
|
<rdfs:label xml:lang="en">MIME content type</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-rdf;Bag'/>
|
|
<rdfs:comment xml:lang="en">
|
|
A string containing a MIME content-type, or a set of such strings,
|
|
indicating the MIME content-types that can be handled.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;schema'>
|
|
<rdfs:label xml:lang="en">Schema identifier</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;string'/>
|
|
<rdfs:comment xml:lang="en">
|
|
A URI that identifies a language or DTD that is recognized by
|
|
the client, or a set of such URIs.
|
|
|
|
Specific values of this attribute may be applicable to certain
|
|
MIME content types. For example, a URI that is associated with
|
|
a resource containing an XML DTD will generally be applicable
|
|
only with text/xml or application/xml content types.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;charWidth'>
|
|
<rdfs:label xml:lang="en">Character display width</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
|
|
<rdfs:comment xml:lang="en">
|
|
For character displays, the number of characters that can be
|
|
rendered across the display. For displays using a proportional
|
|
font, this is the display width in typographical 'em's.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;charHeight'>
|
|
<rdfs:label xml:lang="en">Character display height</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
|
|
<rdfs:comment xml:lang="en">
|
|
For character displays, the number of rows of characters that
|
|
can be displayed.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;charset'>
|
|
<rdfs:label xml:lang="en">Character set encoding</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-rdf;Bag'/>
|
|
<rdfs:comment xml:lang="en">
|
|
For character displays, the MIME 'charset' values that
|
|
can be handled.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;pix-x'>
|
|
<rdfs:label xml:lang="en">Pixel display width</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
|
|
<rdfs:comment xml:lang="en">
|
|
For raster displays, the width of the display in pixels.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;pix-y'>
|
|
<rdfs:label xml:lang="en">Pixel display height</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
|
|
<rdfs:comment xml:lang="en">
|
|
For raster displays, the height of the display in pixels.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
<ccpp:Attribute rdf:about='&ns-ccpp-client;color'>
|
|
<rdfs:label xml:lang="en">Color display capabilities</rdfs:label>
|
|
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
|
|
<rdfs:range rdf:resource='&ns-ccpp;string'/>
|
|
<rdfs:comment xml:lang="en">
|
|
For display or print devices, an indication of the color
|
|
rendering capabilities:
|
|
binary - indicates bi-level color (black-and-white, or similar).
|
|
grey - indicates gray scale capability, capable of sufficient
|
|
distinct levels for a monochrome photograph.
|
|
limited - indicates a limited number of distinct colors, but
|
|
not with sufficient control for displaying a color
|
|
photograph (e.g. a pen plotter, high-light printer or
|
|
limited display).
|
|
mapped - indicates a palettized color display, with enough
|
|
levels and control for coarse display of color
|
|
photographs.
|
|
full - indicates full color display capability.
|
|
</rdfs:comment>
|
|
</ccpp:Attribute>
|
|
|
|
</rdf:RDF></pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h2><a name="Appendix_D"></a>Appendix D: Recommendations for creating a
|
|
vocabulary</h2>
|
|
|
|
<p>This appendix in INFORMATIVE.</p>
|
|
|
|
<p>Fundamental to the design of CC/PP is the idea that new client attributes
|
|
can be defined, as needed, through the introduction of new vocabularies.</p>
|
|
|
|
<p>Similarly, new relationships can be introduced through new vocabulary
|
|
items, though the introduction of these needs a great deal of care to ensure
|
|
their semantics are adequately and consistently defined. A general principle
|
|
is that application-neutral CC/PP processors should be able to understand and
|
|
manipulate CC/PP relationships without necessarily understanding the CC/PP
|
|
attributes to which they refer.</p>
|
|
|
|
<p>It is recommended that RDF Schema be used, in conjunction with supporting
|
|
documentation, to define any new CC/PP vocabulary. The rest of this section
|
|
assumes that RDF Schema is being used for defining any new vocabulary. The
|
|
previous appendix is an example of this approach.</p>
|
|
|
|
<p>New vocabularies are introduced through XML namespaces. Their relationship
|
|
to other CC/PP vocabulary items can be defined by new RDF schema statements
|
|
(which must necessarily augment the core RDF schema for the CC/PP vocabulary
|
|
given in <a href="#Appendix_C">Appendix C</a> of this document).</p>
|
|
|
|
<h3><a name="Basic"></a>D.1 Basic format for all vocabulary items</h3>
|
|
All vocabulary items used by CC/PP are URIs and optional fragment
|
|
identifiers, used as RDF property arc identifiers. Relative URI forms should
|
|
not be used. Vocabulary items used for different purposes are generally
|
|
associated with different XML namespaces. Some common RDF base classes are
|
|
defined so that a schema-aware RDF processor can perform improved analysis of
|
|
a CC/PP profile, and separate CC/PP profile elements from other statements
|
|
made about any resource that appear in the same RDF graph as a CC/PP profile.
|
|
|
|
<p>All properties used as CC/PP attributes must be instances of the class
|
|
<tt>ccpp:Attribute</tt>, which itself is a subclass of <tt>rdf:Property</tt>.
|
|
(That is, the schema defining CC/PP attribute properties should define them
|
|
as instances of <tt>ccpp:Attribute</tt>. Thus, a schema-aware processor can
|
|
distinguish between properties that are part of a CC/PP profile, and
|
|
properties which may be part of an attribute value.)</p>
|
|
|
|
<p>Each CC/PP attribute is associated with a component of a profile (e.g.
|
|
HardwarePlatform, SoftwarePlatform, etc.), and is used as a property of an
|
|
instance of the appropriate component resource. All such component resource
|
|
types are subclasses of <tt>ccpp:Component</tt>. New
|
|
<code>ccpp:Component</code> based classes may be introduced for new types of
|
|
attribute vocabulary, but it is strongly recommended that an existing
|
|
<code>ccpp:Component</code> type be used if one is applicable.</p>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE</i></b>: A simple CC/PP parser is not required to be
|
|
schema-aware, and its implementation does not need to have knowledge of the
|
|
RDF class of any attribute or resource, nor is the profile required to
|
|
carry RDF type information. The discussion of classes and schema-aware
|
|
processing is in relation to possible future developments of generic RDF
|
|
processors that may deal with CC/PP and other RDF vocabularies and schemas,
|
|
possibly mixed in a single document. For such developments to be possible,
|
|
it is important to take account of class and schema issues in the design of
|
|
CC/PP, even though simple CC/PP processors need no such awareness.</p>
|
|
</blockquote>
|
|
|
|
<h3><a name="namespaces"></a>D.2 Use of XML namespaces</h3>
|
|
|
|
<p>All CC/PP attributes must be associated with a fully resolvable namespace
|
|
identifier URI. (Relative URIs, or URIs whose interpretation may depend on
|
|
the context in which they are used, should not be used.)</p>
|
|
|
|
<blockquote>
|
|
<p><em><strong>NOTE</strong></em>: It is anticipated that a namespace URI
|
|
used for CC/PP attributes may also be used to identify an RDF or other
|
|
schema relating to those attributes. However, such usage is beyond the
|
|
scope of this specification.</p>
|
|
</blockquote>
|
|
|
|
<p>Typically, new CC/PP attributes will be associated with a new namespace,
|
|
which serves (among other things) to distinguish between possible different
|
|
uses of the same attribute name local parts. For example, <code>a:foo</code>
|
|
and <code>b:foo</code> name quite distinct attributes as long as the prefixes
|
|
<code>a:</code> and <code>b:</code> are associated with different namespace
|
|
URIs.</p>
|
|
|
|
<h3><a name="Principles"></a>D.3 Principles for defining new attributes</h3>
|
|
|
|
<h4><a name="xtocid-33666567">D.3.1 If possible, reuse existing
|
|
vocabularies</a></h4>
|
|
|
|
<p>Re-using existing vocabularies, where applicable, leverages work that has
|
|
already been undertaken and reduces the opportunity for different attribute
|
|
names that mean almost but not quite the same thing.</p>
|
|
|
|
<p>Note that names using different namespaces may be freely mixed in a
|
|
profile, so requiring one additional feature is not a good reason to define a
|
|
complete new vocabulary.</p>
|
|
|
|
<h4><a name="3.3.2"></a>D.3.2 Attribute value type and interpretation</h4>
|
|
Attribute definitions should indicate the type and interpretation of the
|
|
associated value. Ultimately it is a matter for agreement between generating
|
|
and receiving applications how any particular attribute value is to be
|
|
interpreted.
|
|
|
|
<p>Where possible, for ease of processing and compatibility with other
|
|
frameworks, attribute values should be based on one of the data types
|
|
described in section <a href="#AttributeData">4.1</a> of this document.</p>
|
|
|
|
<p>Where attributes express a quantity associated with a client, the units of
|
|
that quantity should be clearly associated with the attribute definition.
|
|
There is no separate mechanism for indicating the units in which an attribute
|
|
value is expressed.</p>
|
|
|
|
<h4><a name="3.3.3"></a>D.3.3 Interpretation not dependent on other attribute
|
|
values</h4>
|
|
The meaning of every attribute must be defined in isolation from other
|
|
attributes: no attribute may have a meaning that changes dependent on the
|
|
value of some other attribute. E.g. an attribute called, say, page-width must
|
|
always be expressed using the same units: it is not acceptable for this
|
|
attribute to be expressed in characters for some class of device, millimeters
|
|
for another, and inches for another. (Note that it is still allowable to
|
|
define an attribute that cannot be interpreted unless some other attribute is
|
|
also defined; the important principle here is that adding a new attribute
|
|
should not invalidate any knowledge of a client that can be deduced from
|
|
attributes previously defined.)
|
|
|
|
<p>Attributes may be defined in "layers", so that simple capabilities (e.g.
|
|
ability to handle color photographic images) can be described by a simple
|
|
attribute, with additional attributes used to provide more detailed or arcane
|
|
capabilities (e.g. exact color matching capabilities).</p>
|
|
|
|
<h4><a name="3.3.4"></a>D.3.4 Attribute naming conventions</h4>
|
|
Attributes are RDF properties. The RDF Model and Syntax document <a
|
|
href="#3">[RDF]</a>, Appendix C, recommends the use of "interCap" name styles
|
|
for RDF property names (starting with a lowercase letter, and having 2nd and
|
|
subsequent words within a name started with a capital letter and no internal
|
|
punctuation). We recommend such style be used for CC/PP attribute names,
|
|
except where some other form is preferred for compatibility with other
|
|
systems (such as some CONNEG-compatible print and display attributes
|
|
described below).
|
|
|
|
<p>RDF class names used in CC/PP profiles preferably begin with an uppercase
|
|
letter.</p>
|
|
|
|
<h4><a name="AttributeApplicability"></a>D.3.5 Attributes should have
|
|
specific applicability</h4>
|
|
|
|
<p>If an attribute is defined with a broad range of applicability, problems
|
|
could arise if a user tries to apply a single attribute to different parts of
|
|
a profile.</p>
|
|
|
|
<p>An attribute defined very broadly might be subject to different privacy or
|
|
security concerns when applied in different circumstances. For example,
|
|
having a text-to-voice capability on a mobile phone type of device might be a
|
|
generally useful feature, but a similar feature in a PC might be indicative
|
|
of a personal disability. Thus a combination of text-to-voice capability and
|
|
using a PC-type platform might suggest private information not necessarily
|
|
associated with any of the features in isolation.</p>
|
|
|
|
<h3><a name="ProtocolInteractions"></a>D.4 Protocol interactions</h3>
|
|
|
|
<p>In some cases, there may be overlaps between CC/PP vocabularies and a
|
|
particular protocol with which CC/PP is used. E.g. the client vocabulary
|
|
<i>charset</i> and the HTTP <code>accept-charset:</code> header. To some
|
|
extent, the protocol-independent nature of CC/PP makes this inevitable, to
|
|
the extent that existing protocols may have limited content negotiation
|
|
facilities.</p>
|
|
|
|
<p>When designing vocabularies, avoid defining features which would be
|
|
expected to be part of a particular protocol behavior; anything that
|
|
describes or relates to a transfer mechanism rather than what is transferred
|
|
should be avoided; e.g. support for a feature like HTTP persistent
|
|
connections should not be indicated in a CC/PP profile, as (a) it is a
|
|
protocol-specific feature, and (b) it doesn't really help the origin server
|
|
to select appropriate content for the client.</p>
|
|
|
|
<p>Similarly, when defining protocol bindings for using CC/PP, interaction
|
|
with existing negotiation mechanisms should be considered and specified. A
|
|
detailed treatment of this topic is beyond the scope of this
|
|
specification.</p>
|
|
|
|
<h2><a name="Appendix_E"></a>Appendix E: Review of applicable
|
|
vocabularies</h2>
|
|
|
|
<p>This appendix is INFORMATIVE.</p>
|
|
|
|
<p>This section introduces some possible sources of properties to be
|
|
described by CC/PP attribute vocabularies. It is not normative, and is
|
|
included to give an idea of some kinds of client feature that CC/PP might be
|
|
used to convey.</p>
|
|
|
|
<h3><a name="IETF"></a>E.1 IETF media feature registration (CONNEG)</h3>
|
|
The IETF has defined an IANA registry for media feature tags <a
|
|
href="#5">[RFC2506]</a> and a syntax <a href="#6">[RFC2533]</a> for
|
|
relational-style expressions using these to describe client and server media
|
|
features. A small common vocabulary has been defined <a
|
|
href="#8">[RFC2534]</a>, which has been used as a basis for the CC/PP client
|
|
common vocabulary. The IETF Internet fax Working Group has also created
|
|
additional registrations to describe the capabilities of fax machines <a
|
|
href="#16">[RFC2531]</a>.
|
|
|
|
<p>RFC 2506 <a href="#5">[RFC2506]</a> defines three kinds of media feature
|
|
tags:</p>
|
|
<ul>
|
|
<li><i>IETF tree</i>: registered feature tags that are simple names, which
|
|
are defined and assigned under the auspices of the IETF standards
|
|
process.</li>
|
|
<li><i>Global tree</i>: registered feature tags that are simple names
|
|
preceded by <tt>'g.'</tt>. These are defined by groups other than the
|
|
IETF, but are registered with IANA to ensure uniqueness of these
|
|
names.</li>
|
|
<li><i>Unregistered</i>: feature tags that consist of <tt>'u.'</tt>
|
|
followed by a slightly restricted form of URI.</li>
|
|
</ul>
|
|
There is currently a proposal to create a URN namespace for IANA registries.
|
|
This would create a mechanism to allow IANA-registered feature tags to be
|
|
used directly as URIs in CC/PP expressions.
|
|
|
|
<p>Unregistered feature tags may be used in CC/PP expressions by stripping
|
|
off the leading '<tt>u.</tt>' and taking the resulting URI.</p>
|
|
|
|
<p>All media feature tags and values can be expressed in CC/PP, but not all
|
|
CC/PP profiles can be expressed as media feature tags and values. In
|
|
particular, CC/PP text values are case sensitive whereas some media feature
|
|
values are case insensitive. Media feature values can be mapped to CC/PP text
|
|
values by applying a case-normalization convention (e.g. convert to
|
|
lowercase).</p>
|
|
|
|
<p>This version of CC/PP does not have mechanisms matching those in the IETF
|
|
media feature framework, which can be used within CC/PP to state capabilities
|
|
in terms of comparisons with fixed values (e.g. '<tt>pix-x<=640</tt>') and
|
|
attribute values that appear in certain combinations (e.g.
|
|
'<tt>pix-x=640</tt>' AND '<tt>pix-y=480</tt>' OR '<tt>pix-x=800</tt>' AND
|
|
'<tt>pix-y=600</tt>'). Future work may define such mechanisms.</p>
|
|
|
|
<h3><a name="UAPROF"></a>E.2 WAP UAProf</h3>
|
|
UAProf <a href="#9">[UAPROF]</a> is a WAP Forum specification that is
|
|
designed to allow wireless mobile devices to declare their capabilities to
|
|
data servers and other network components.
|
|
|
|
<p>The design of UAProf is already based on RDF. As such, its vocabulary
|
|
elements use the same basic format that is used for CC/PP.</p>
|
|
|
|
<p>The CC/PP model follows UAProf, in that each user agent property is
|
|
defined as belonging to one of a small number of components, each of which
|
|
corresponds to an aspect of a user agent device; e.g.</p>
|
|
<ul>
|
|
<li>Hardware platform</li>
|
|
<li>Software platform</li>
|
|
<li>WAP characteristics</li>
|
|
<li>Browser user agent</li>
|
|
<li>Network characteristics</li>
|
|
</ul>
|
|
|
|
<p>Although its RDF schema is more prescriptive regarding class and property
|
|
usage than UAProf, the design of CC/PP is backwards compatible. The goal is
|
|
that valid UAProf profiles are also valid CC/PP profiles; however not all
|
|
CC/PP profiles are necessarily valid UAProf profiles.</p>
|
|
|
|
<h3><a name="TIFF"></a>E.3 TIFF</h3>
|
|
TIFF is a raster image encapsulation file format developed and maintained by
|
|
Adobe Systems <a href="#17">[TIFF]</a>. It is also the basis for the standard
|
|
file format for Internet Fax <a href="#18">[RFC2301]</a>.
|
|
|
|
<p>As well as pixel-based image data in a variety of coding and compression
|
|
formats, TIFF supports a wide range of options for different kinds of
|
|
image-related information. These options might be candidate CC/PP attributes.
|
|
Many of the TIFF properties relating to image handling capabilities have
|
|
already been defined as tags in the CONNEG space as part of the Internet Fax
|
|
work <a href="#16">[RFC2531]</a>; these might best be referenced using URIs
|
|
based on their CONNEG tag names.</p>
|
|
|
|
<h3><a name="WAVE"></a>E.4 WAVE</h3>
|
|
WAVE is an encapsulation format for audio data, developed and maintained by
|
|
Microsoft <a href="#19">[MULTIMEDIA]</a>.
|
|
|
|
<p>There is a registry of WAVE-supported audio codecs that might be used as
|
|
CC/PP attributes <a href="#20">[RFC2361]</a>.</p>
|
|
|
|
<p>IETF work in progress for voice messaging (VPIM/IVM) could create IETF
|
|
media feature registry tags that are usable by CC/PP profiles through the
|
|
same mechanisms described in section <a href="#IETF">E.1</a> above.</p>
|
|
|
|
<h3><a name="MPEG-4"></a>E.5 MPEG-4</h3>
|
|
MPEG-4 is an encapsulation format for video data, possibly combined with
|
|
audio data, developed and maintained by the ISO MPEG Working Group <a
|
|
href="#21">[MPEG]</a>.
|
|
|
|
<h3><a name="MPEG-7"></a>E.6 MPEG-7</h3>
|
|
MPEG-7 is a metadata format for information associated with image, video,
|
|
audio and other data, currently in development by the ISO MPEG Working Group
|
|
<a href="#26">[MPEG-7]</a>.
|
|
|
|
<h3><a name="PWG"></a>E.7 PWG</h3>
|
|
The printer Working Group defines attributes and capabilities applicable to
|
|
printing devices <a href="#22">[PWG]</a>. Some of this work is incorporated
|
|
into the IETF Internet Printing Protocol (IPP) <a href="#23">[RFC2566]</a>.
|
|
|
|
<h3><a name="Salutation"></a>E.8 Salutation</h3>
|
|
Salutation is a protocol and identification scheme for communicating devices,
|
|
mainly in a LAN environment, developed and maintained by the Salutation
|
|
Consortium <a href="#24">[SALUTATION]</a>. The device capability
|
|
identification mechanisms probably include many items that might be used as
|
|
CC/PP attributes.
|
|
|
|
<h2><a name="Appendix_F"></a>Appendix F: CC/PP applications</h2>
|
|
|
|
<p>This appendix is INFORMATIVE.</p>
|
|
|
|
<p>CC/PP is a format framework designed to be used in the context of a wider
|
|
application or operational environment. This specification does not define
|
|
how to use CC/PP with any particular protocol or application.</p>
|
|
|
|
<p>This appendix highlights some other issues that application developers
|
|
must consider in their designs. Many of these issues may be covered by an
|
|
applicable protocol specification used to convey CC/PP profiles.</p>
|
|
|
|
<p>To make effective use of the CC/PP framework, the operating rules for the
|
|
wider environment must specify:</p>
|
|
<ul>
|
|
<li>Capability exchange protocol</li>
|
|
<li>Trust model</li>
|
|
<li>Vocabulary</li>
|
|
<li>Security mechanisms</li>
|
|
<li>Constraints on allowable attribute value types</li>
|
|
<li>Attribute value processing and/or matching rules</li>
|
|
<li>Proxy vocabulary and processing</li>
|
|
<li>Rules for request profile identification</li>
|
|
<li>Additional information to be included with any transmitted resource
|
|
data</li>
|
|
<li>URI forms allowed for identifying referenced profile documents (e.g.
|
|
defaults)</li>
|
|
<li>Mechanisms for locating and retrieving referenced profile documents</li>
|
|
<li>Interactions with any existing negotiation mechanisms in the host
|
|
protocol</li>
|
|
</ul>
|
|
|
|
<p>There are a few protocol assumptions built into the design of CC/PP.
|
|
Although it is intended to be largely protocol independent, some
|
|
consideration has been given to use of CC/PP with HTTP for retrieving Web
|
|
resources.</p>
|
|
|
|
<h3><a name="Outline"></a>F.1 Outline of request processing in HTTP</h3>
|
|
|
|
<p>CC/PP is envisaged to be used with HTTP in the following fashion.</p>
|
|
|
|
<p>(This is not a protocol specification, just an indication of the kind of
|
|
information flows envisaged. Defining a protocol to convey CC/PP information
|
|
is a separate effort <a href="#35">[CCPPEX]</a>).</p>
|
|
|
|
<table summary="Figure F-1" border="1" cellspacing="2" cellpadding="2"
|
|
bgcolor="#FFCC99">
|
|
<caption align="bottom">Figure F-1: HTTP request processing</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td><pre> +------+ (5) (4) +-------+ +------+
|
|
|Client| <==response== | Proxy | <==response== |Origin| <====> (Resource)
|
|
| UA | ===request==> | | ===request==> |server| (3) ( data )
|
|
+------+ (1) | +-------+ (2) | +------+
|
|
| |
|
|
v v
|
|
(Client ) <--- (Client profile) <----- (Request profile)
|
|
(defaults) + local values |
|
|
v
|
|
(Proxy ) <--- (Proxy profile)
|
|
(defaults) + local values</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<ol>
|
|
<li>The client sends an HTTP request, with an accompanying CC/PP client
|
|
profile. The client profile may contain references to default profiles
|
|
describing a range of common capabilities for the client concerned (e.g.
|
|
a particular computer/operating system/browser combination, or a
|
|
particular model of mobile device), and values that are variations from
|
|
the default profile.</li>
|
|
<li>The HTTP request may pass through a firewall/proxy that (a) imposes
|
|
constraints on the kinds of content that can be accessed, or (b) can
|
|
adapt other forms of content to the capabilities of the requesting
|
|
client. This proxy extends the CC/PP profile with a description of these
|
|
constraints and adaptations, and sends this with the HTTP request on to
|
|
the origin server. The request may pass through several such proxies.</li>
|
|
<li>The origin server receives the request and interprets the CC/PP
|
|
profile. It selects and/or generates content that matches the combined
|
|
proxy and client capabilities described in the profile. This is sent to
|
|
the last proxy in the request chain in an HTTP response.</li>
|
|
<li>If required, the proxy applies any content adaptations, and any other
|
|
functions it is designed to perform. The resulting response and content
|
|
is passed back toward the requesting client.</li>
|
|
<li>The client receives the HTTP response and presents the content it
|
|
contains.</li>
|
|
</ol>
|
|
|
|
<blockquote>
|
|
<p><b><i>NOTE</i></b>: There is some overlap between CC/PP and the various
|
|
HTTP accept-* headers. A protocol specification for using CC/PP with HTTP
|
|
must indicate how HTTP 'accept-*' headers may be used, and how they
|
|
interact with CC/PP profiles.</p>
|
|
</blockquote>
|
|
|
|
<h3><a name="ProtocolAssumptions"></a>F.2 Protocol assumptions for proxy
|
|
behavior</h3>
|
|
|
|
<p>The framework for describing proxy behaviors makes some assumptions about
|
|
the protocol used to convey a CC/PP profile:</p>
|
|
<ul>
|
|
<li>The CC/PP profile is conveyed in one or more parts, each containing a
|
|
graph fragment, which are combined to form a single RDF graph.</li>
|
|
<li>In addition to the RDF graph, the protocol must separately name the RDF
|
|
resource corresponding to the root of the current request profile.</li>
|
|
<li>The current operational model is that all CC/PP profile interpretation
|
|
is performed by the origin server, and none by the proxies. It may be
|
|
necessary for the protocol to allow the origin server to provide
|
|
information with its response that allows proxies to decide whether or
|
|
not to apply any conversions that they offer; e.g. is XHTML-to-WML
|
|
conversion required, or does the client have native XHTML capability?
|
|
<p><b><i>NOTE</i></b>: The "current operational model" noted above does
|
|
not prohibit proxies from interpreting CC/PP profiles. Rather, it means
|
|
that the framework for describing proxy behaviors does not require that
|
|
proxies interpret them.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<h2><a name="Appendix_G"></a>Appendix G: RDF Compatibility</h2>
|
|
|
|
<p>This appendix is INFORMATIVE.</p>
|
|
|
|
<p>This CC/PP specification is based on Resource Description Framework (RDF)
|
|
Model and Syntax Specification <a href="#3">[RDF]</a>, a W3C Recommendation.
|
|
That version of RDF does not have explicit datatyping of literals. The RDF
|
|
specifications have been undergoing revision as this specification is being
|
|
written. The revised RDF (<a href="/TR/rdf-syntax-grammar/">RDF/XML Syntax
|
|
Specification (Revised)</a>), which at the time of writing has not reached
|
|
recommendation status, introduces support for specifying the XML Schema
|
|
datatype of a literal value. This appendix outlines the implications for
|
|
implementors in making their CC/PP implementations compatible with this
|
|
proposed addition to RDF. It is hoped that a future version of the CC/PP
|
|
specification will propose how explicit datatyping should be used in defining
|
|
CC/PP profiles.</p>
|
|
|
|
<h3><a name="RDFImplicitDatatyping">G.1 Implicit datatyping</a></h3>
|
|
|
|
<p>In this specification, a CC/PP attribute value contained in a CC/PP
|
|
profile is, in RDF (Revised) <a href="#rdfprimer">[RDFPRIMER]</a>
|
|
terminology, an <a href="/TR/rdf-concepts/#dfn-plain-literal">RDF Plain
|
|
Literal</a>. A CC/PP vocabulary schema (such as the example in <a
|
|
href="#Appendix_C">Appendix C</a>), that is defined in terms of the simple
|
|
types introduced in the CC/PP schema (in <a href="#Appendix_B">Appendix
|
|
B</a>), can provide additional type information for these attributes. A CC/PP
|
|
profile consumer application may use the vocabulary schema (either by
|
|
directly interpreting the schema data, or, for known vocabularies, by
|
|
embedding the equivalent information in the application) to check the
|
|
validity of the data provided in a profile, and to map the data into
|
|
programming language data types.</p>
|
|
|
|
<h3><a name="RDFExplicitDatatyping">G.2 Explicit datatyping</a></h3>
|
|
|
|
<p>The revised RDF Working Draft supports explicit XSD (<a
|
|
href="/TR/xmlschema-2/">XML Schema Datatypes</a>) datatyping. When explicit
|
|
datatyping is adopted, the CC/PP specification could be revised to permit an
|
|
attribute value in a CC/PP profile to be represented as an <a
|
|
href="/TR/rdf-concepts/#dfn-typed-literal">RDF Typed Literal</a>. In the <a
|
|
href="/TR/rdf-syntax-grammar/#section-Syntax-datatyped-literals">XML
|
|
serialization of an RDF Typed Literal</a>, the type of the literal value is
|
|
specified as an attribute of the element containing the literal value. In
|
|
this case, a CC/PP profile consumer application could use this type
|
|
information to interpret the CC/PP attribute value, without requiring access
|
|
to additional vocabulary schema information.</p>
|
|
|
|
<p>In the future it may be that, for backward compatibility, a CC/PP profile
|
|
consumer should be able to handle CC/PP attributes that use either implicit
|
|
or explicit datatyping.</p>
|
|
|
|
<h2><a name="RevisionHistory"></a>Appendix W: Revision history</h2>
|
|
|
|
<table summary="Revision history" style="width: 80%;" border="1">
|
|
<tbody>
|
|
<tr>
|
|
<td width="20%" valign="top">20001218</td>
|
|
<td width="80%" valign="top">Document created from merge of
|
|
architecture, structure and vocabulary documents.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20001219</td>
|
|
<td width="80%" valign="top">Move some vocabulary and proxy material
|
|
from section to into sections 3 and 4. Various small edits.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" height="18" valign="top">20010109</td>
|
|
<td width="80%" height="18" valign="top">Various editorial fixes. Merge
|
|
appendices dealing with print and display vocabulary. Remove some
|
|
vocabulary source references. Add XML examples to many of the RDF
|
|
graph examples. Reorganize material in sections 2 and 3, moving some
|
|
technical detail to section 3. Move discussion of CC/PP applications
|
|
to a new appendix. Assign figure numbers.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010112</td>
|
|
<td width="80%" valign="top">More group review editorial comments.
|
|
Fixed some schema errors. Moved client schema summary to appendix C.
|
|
Updated UAProf reference and namespace URI. Added Working Group
|
|
members to acknowledgments.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010116</td>
|
|
<td width="80%" valign="top">More group review editorial comments.
|
|
Added citation of RFC2119. Changed some instances of rdf:Bag to {...}
|
|
notation in graph descriptions. Use ccpp:defaults consistently in
|
|
examples; add note about allowing ccpp:Defaults for compatibility
|
|
with UAProf. Section 2.1.3: added some additional text about
|
|
references to external defaults. Added points for allowed URIs and
|
|
resolution mechanisms in appendix F. Figure 3-12 notation change.
|
|
Section 4.1: attempt to further clarify what is required behavior.
|
|
Section 4.3, add paragraph about support of RDF schema. Appendix D:
|
|
add text recommending use of RDF schema to define vocabularies.
|
|
Section 3.1.1, add text about use of rdf:type properties for
|
|
ccpp:Component resources. Appendix B: remove references to ccpp:Set
|
|
and ccpp:Value.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010118</td>
|
|
<td width="80%" valign="top">Validate RDF examples with SiRPAC (W3C
|
|
online facility) and correct errors detected. Fix up some internal
|
|
links.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010129</td>
|
|
<td width="80%" valign="top">Add hyperlinked ToC (courtesy of "htmltoc"
|
|
by Earl Hood)</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010223</td>
|
|
<td width="80%" valign="top">Published as First Working Draft.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010315</td>
|
|
<td width="80%" valign="top">Added last-call section. Changed some
|
|
spelling. Published as Last-call working Working Draft.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010425</td>
|
|
<td width="80%" valign="top">Fold in review comments for editorial
|
|
matters. Explain use of names for URIs in examples. Remove unused
|
|
terms from glossary.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010510</td>
|
|
<td width="80%" valign="top">Remove P3P from glossary; P3P integration
|
|
will be discussed in a separate security document. Review all
|
|
examples to use full URIs rather than placeholder names, and qualify
|
|
all RDF attributes with namespace prefixes. Added cross-reference
|
|
from section 2.3 to 3.1.4 and 3.1.5 (CC/PP usage of RDF). Added NOTE
|
|
saying why proxy descriptions are not linked directly. Added sequence
|
|
value to data types. Remove requirement for an attribute to be unique
|
|
across all components of a profile. Added restriction that a single
|
|
"Proxy-behavior" must reference a single type of component, and that
|
|
the component type should be specified (section 3.2.2). Clarify that
|
|
'charset' feature really indicates a character encoding. Appendix F
|
|
re-worked to make it clearer that this document does not define an
|
|
HTTP binding for using CC/PP. Added 'xml:lang' attributes to schemas
|
|
in appendices B and C. Revise interpretation of charWidth to better
|
|
cater for international characters.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010511</td>
|
|
<td width="80%" valign="top">Reference XML schema data types, and fix
|
|
up some minor schema errors. Introduce new class ccpp:Structure to
|
|
clearly distinguish all CC/PP structural properties from attribute
|
|
properties. Editorial fix in relationship to UAProf (E.2).</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010522</td>
|
|
<td width="80%" valign="top">Revise text relating to CC/PP attributes
|
|
that are represented by URI strings: preferred treatment is as RDF
|
|
resources rather than literal URI strings (section 4.1.1.1 and
|
|
various examples). Discussion of graph composition (new section
|
|
3.1.6). Deleted some gratuitous repetition (sections 3.1.1 and
|
|
3.1.2).</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010620</td>
|
|
<td width="80%" valign="top">Revise all examples to use explicit
|
|
namespace prefixes for RDF elements and attributes. Remove unused
|
|
ccpp: namespace declaration from some examples.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010704</td>
|
|
<td width="80%" valign="top">Fix small errors in examples 2-3b and
|
|
3-2c. Editorial fixes.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20010906</td>
|
|
<td width="80%" valign="top">Reword text in 3.1.5 describing use of
|
|
rdf:type on ccpp:Component instance. Revise description of
|
|
'charWidth' in appendix C to remove some errors with respect to
|
|
international characters. Section 4.1.1.1: Added some text indicating
|
|
that XML conventions must be used for encoding non-ASCII characters
|
|
in URI values (per RDF spec). Section 4.1.2.2: added note that
|
|
vocabularies that use sequence values should define the significance
|
|
of the ordering. Add text pointing about possible protocol
|
|
interactions to appendices D, F and F.1. Checked example of empty
|
|
description element with RDF validator.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20011102</td>
|
|
<td width="80%" valign="top"><p>Revise the wording in section 4.1.1.1
|
|
about encoding of non-ASCII characters in URI values, to reference
|
|
the XML specification errata <a
|
|
href="/XML/xml-V10-2e-errata#E26">http://www.w3.org/XML/xml-V10-2e-errata#E26</a>.
|
|
Updated reference [XML] to cite the errata document. Revision to
|
|
section 4.1.2 introduction text to clarify that arbitrary RDF
|
|
resources may be used for attribute values, though their meaning is
|
|
not defined here. Fix typo.</p>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020402</td>
|
|
<td width="80%" valign="top">Add hyperlinks to schema documents.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020501</td>
|
|
<td width="80%" valign="top">Added the term 'XML attributes' where
|
|
necessary to distinguish between CC/PP attributes and XML attributes.
|
|
Fixed the local about reference in Figure 2-1b. Added 'section'
|
|
hyperlinks where necessary. Removed unnecessary angle brackets around
|
|
namespace identifiers. Removed extraneous space from date of Working
|
|
Group meeting. Removed the proxy hardware and software examples:
|
|
there is no need for a proxy to append its processor or operating
|
|
system to a CC/PP request and using this as an example will cause
|
|
confusion. Removed some remaining instances of the term 'URI string'.
|
|
Changed 'don't reuse existing vocabularies' heading to 'reuse
|
|
existing vocabularies'. Removed an unnecessarily capitalized
|
|
'Defaults' from Section 3.1.3. Fixed the references so they work:
|
|
there was a problem with the square brackets. Changed 'RDF schema' to
|
|
'RDF Schema' where it is used to refer to the W3C specification.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020502</td>
|
|
<td width="80%" valign="top">Fixed errors in RDF in Figure 1-2 and
|
|
Figure 3-3 identified with W3C RDF validation service.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020507</td>
|
|
<td width="80%" valign="top">Updated section 3.1.5 to resolve issue 16.
|
|
Updated section 2.2 to resolve issue 54. Added a paragraph about WAI
|
|
to resolve issue 115.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020520</td>
|
|
<td width="80%" valign="top">Updated CC/PP schema to create datatypes
|
|
for anyURI, string and integer in the CC/PP namespace that reference
|
|
the datatypes in the XML Schema. The previous version of the schema
|
|
just referenced the XML schema datatypes. Changed CC/PP namespace to
|
|
<a
|
|
href="/2002/05/20-ccpp#">http://www.w3.org/2002/05/20-ccpp#</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020715</td>
|
|
<td width="80%" valign="top">Updated the reference section to
|
|
distinguish between normative and informative references and use
|
|
[AAAA] not [nnnn] reference label format as per W3C Style Guide to
|
|
address issue 181. Removed examples using composite literals i.e.
|
|
changed all instances of <code><display></code> to
|
|
<code><displayWidth></code> and
|
|
<code><displayHeight></code> to address issue 152. Changed
|
|
example profiles so that rdf:about's point to a profile URI rather
|
|
than a schema URI as this means the component applies to this
|
|
particular profile instance, rather than any device using this
|
|
particular schema to address issue 153. Added some text to section
|
|
3.1.1 to address issue 175. Inserted Figure 3.2b to explain default
|
|
resolution to address issue 180.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020717</td>
|
|
<td width="80%" valign="top">Updated the UAProf URL, specifically in
|
|
Section 2.2, and added text proposed by Art Barstow to resolve issue
|
|
54. Also updated UAProf examples so they use legal UAProf property
|
|
names.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020719</td>
|
|
<td width="80%" valign="top">Removed a remaining instance of the
|
|
sentence "This is one of three properties to describe a proxy
|
|
behavior." to address issue 37.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020812</td>
|
|
<td width="80%" valign="top">Added a sentence to section 3.2 and three
|
|
additional paragraphs to section 3.2.2 to address issue 182.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020812</td>
|
|
<td width="80%" valign="top">Changed a paragraph in section 3.2 to
|
|
address issue 182.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20020924</td>
|
|
<td width="80%" valign="top">Removed usage of ccpp:Resource to resolve
|
|
issue 31.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20021105</td>
|
|
<td width="80%" valign="top">Altered text of abstract to indicate proxy
|
|
vocabulary is optional. Altered text of introduction to indicate
|
|
proxy vocabulary is optional. Added a preceding sentence in section
|
|
2.1.4 saying proxy support is optional. Ditto for section 2.2. Moved
|
|
Client-profile, Request-profile, Proxy-profile and Proxy-Behavior
|
|
from CCPP Schema to proxy Schema. Updated figures B.1 and B.2 and
|
|
added two new figures, B.3 and B.4 to reflect this. Due to the data
|
|
typing decision made by RDF-Core concerning interpreting literals,
|
|
changed all instances of XML Schema datatypes to CC/PP data types.
|
|
Removed the sentence "Note that, where available, XML schema
|
|
datatypes (xsdt:) are used for literal values [XMLSCHEMA-2]." from
|
|
section B.1. Updated URIs to 08 November 2002. Changed definition of
|
|
CC/PP profile in Section 2.1 to "A CC/PP profile is broadly
|
|
constructed as a 2-level hierarchy: a profile having a number of
|
|
components, and each component having at least one or more
|
|
attributes." to resolve the concern expressed by the UAProf drafting
|
|
committee that the CC/PP definition of a component is incompatible
|
|
with UAProf.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20021211</td>
|
|
<td width="80%" valign="top">Fixed problem with Figure 2-3b described
|
|
in issue 183. Clarified meaning of CC/PP profile for issue 185.
|
|
Clarified the status of appendices to address issue 189. Removed the
|
|
term "CC/PP expression" from section 2.2 to address issue 191.
|
|
Updated the RDF Schema reference to point at the March 2000 Candidate
|
|
Recommendation version. Fixed UAProf reference to address issue 198.
|
|
Fixed schema in B.3 to address issue 200. Updated introductory
|
|
paragraph to Appendix C to address issue 201. Added a definition of a
|
|
"CC/PP processor" to appendix B to address issue 202 and replaced
|
|
instance of "CC/PP parser" with CC/PP processor.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20021213</td>
|
|
<td width="80%" valign="top">Checked usage of optional and recommended
|
|
so that instances are capitalized where necessary to address issue
|
|
188.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20030203</td>
|
|
<td width="80%" valign="top">Fixed the use of both
|
|
http://www.w3.org/2002/12/13-ccpp-schema and
|
|
http://www.w3.org/2002/12/13-ccpp as CC/PP namespaces. Uniformly
|
|
adopted the use of rdf:about in the schemas.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20030212</td>
|
|
<td width="80%" valign="top">Fixed problem with section 2 in toc. Fixed
|
|
bold # in CC/PP namespace in section 2.2. Fixed grammatical error in
|
|
section 4.1.2.2.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20030320</td>
|
|
<td width="80%" valign="top">Added mention of RDF data typing and
|
|
further DIWG work to status section. Added mention of compatibility
|
|
with CONNEG to section 1. Removed use of compound simple types in
|
|
examples in section 2.1.3. Removed section 2.1.4 (introduction to
|
|
proxies), section 2.3 (rdf primer), section 3.2 (proxies). Ensured
|
|
the document references the RDF specs (RDF M&S, RDF/XML Syntax,
|
|
RDF Primer, RDF Schema) in appropriate places. Promoted section 3.1
|
|
subsections to section 3 subsections. Removed case-insensitive text
|
|
from section 4.1.1.2. Changed minimum recommended value for integer
|
|
numbers and corrected the XML schema datatype in section 4.1.1.3.
|
|
Described difficulty of rational numbers in section 4.1.1.4.
|
|
Clarified expressive relationship with CONNEG in section E.1.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20030728</td>
|
|
<td width="80%" valign="top">Removed remnants mentioning proxy. Added
|
|
note about RDF Primer referencing more recent versions of RDF specs
|
|
in status section. Changed schema URL from
|
|
http://www.w3.org/2002/11/08-ccpp to
|
|
http://www.w3.org/2002/11/08-ccpp-schema in section 2.2. Added UAProf
|
|
namespace compatibility for component and defaults in section 3.1 and
|
|
3.3. Changed HTML 3.0 to HTML 3.2 in various examples. Removed Tokens
|
|
from section 4.1.1.2 and Appendix C. Fixed rational number schema in
|
|
section 4.1.1.4. Clarified that multiple occurences of a single
|
|
attribute within a single component are not allowed in section 4.1.2.
|
|
Added section 5 Conformance. Changed references to point to dated
|
|
copies in section 7. Removed anyURI from schema in Appendices B and
|
|
C. Changed Rational datatype to rational in Appendix B. Added note
|
|
about case normalization for CONNEG compatibility in section E.1.
|
|
Added Appendix G RDF Compatibility.</td>
|
|
</tr>
|
|
<tr>
|
|
<td width="20%" valign="top">20030915</td>
|
|
<td width="80%" valign="top">Various editorial changes and
|
|
clarifications. Added "delivery context" term to section 1. Removed
|
|
redundant paragraph regarding namespace URIs in section 2.2. Removed
|
|
section 4.1.1.1 "Values described by URIs" since it should have been
|
|
removed when anyURI was removed.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<hr>
|
|
|
|
<p align="left"><a href="http://validator.w3.org/"><img
|
|
src="http://www.w3.org/Icons/valid-html401.gif" alt="Valid HTML 4.01!"
|
|
border="0" height="31" width="88"></a></p>
|
|
</body>
|
|
</html>
|