W3C

Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0

W3C Working Draft 8 December 2006

This version:
http://www.w3.org/TR/2006/WD-CCPP-struct-vocab2-20061208
Latest version:
http://www.w3.org/TR/CCPP-struct-vocab2/
Editor:
Cédric Kiss, W3C

The English version of this specification is the only normative version. Non-normative translations may also be available.


Abstract

This document describes CC/PP (Composite Capabilities/Preference Profiles) Structure and Vocabularies 2.0. A CC/PP profile is a description of device capabilities and user preferences. This is often referred to as a device's delivery context and can be used to guide the adaptation of content presented to that device.

The Resource Description Framework (RDF) is used to create profiles that describe user agent capabilities and preferences. The structure of a profile is discussed. Topics include:

Version 2.0 of CC/PP ensures its alignment with the latest version of RDF.

CC/PP vocabulary is identifiers (URIs) used to refer to specific capabilities and preferences, and covers:

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is the First Public Working Draft of a possible future W3C Recommendation.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document has been produced by the W3C Device Independence Working Group as part of the Device Independence Activity within the W3C Ubiquitous Web Domain. Continued status of the work is reported on the Device Independence Working Group Home Page (Member-only link).

The public is invited to send comments or reports errors to the editors at www-di@w3.org, the public forum for discussion of W3C's work on Device Independence (which encompasses Mobile Web Access). An archive is available at http://lists.w3.org/Archives/Public/www-di/.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

1. Introduction

This document describes CC/PP 2.0 (Composite Capabilities/Preference Profiles 2.0) structure and vocabularies, and is an update of the older CC/PP 1.0 specification [CCPP1]. A CC/PP profile is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device. Here "profile" does not refer to a subset of a particular specification, for example the CSS Mobile profile, but refers to the document(s) exchanged between devices that describe the capabilities of a device.

As the number and variety of devices connected to the Internet grow, there is a corresponding increase in the need to deliver content that is tailored to the capabilities of different devices. Some limited techniques, such as HTTP 'accept' headers and HTML 'alt=' attributes, already exist. As part of a framework for content adaptation and contextualization, a general purpose profile format is required that can describe the capabilities of a user agent and preferences of its user. CC/PP is designed to be such a format.

CC/PP is based on RDF, the Resource Description Framework, which was designed by the W3C as a general purpose metadata description language. RDF provides the framework with the basic tools for both vocabulary extensibility, via XML namespaces [XMLNAMESPACES], and interoperability. RDF is a standard format for data interchange on the Web. There is a specification that describes the complete semantics of RDF [RDF], as well as of the RDF Schema description language [RDFSCHEMA]. RDF can be serialized into XML using the RDF/XML format as defined in [RDFXML]. This serialization is used in this document. For an introduction to RDF, see also the RDF Primer [RDFPRIMER]. RDF is a natural choice for the CC/PP framework since user agent profiles are data intended primarily for communication between user agents and resource data providers.

Editor's note: We will discuss whether serializations of RDF other than XML (like Turtle) are permissible in the case of CC/PP 2.0.

A CC/PP profile contains a number of CC/PP attribute names and associated values that are used by a server to determine the most appropriate form of a resource to deliver to a client. It is structured to allow a client to describe its capabilities by reference to a standard profile, accessible to an origin server or other sender of resource data, and a smaller set of features that are in addition to or different than the standard profile. A set of CC/PP attribute names, permissible values and associated meanings constitute a CC/PP vocabulary.

Some information contained in a profile may be sensitive, and adequate trust and security mechanisms must be deployed to protect users' privacy. As a part of a wider application, CC/PP cannot fully cover such issues, but is intended to be used in conjunction with appropriate mechanisms. This topic is covered in Appendix F (CC/PP applications).

It is anticipated that different applications will use different vocabularies; indeed this is needed if application-specific properties are to be represented within the CC/PP framework. But for different applications to work together, some common vocabulary, or a method to convert between different vocabularies, is needed. (XML namespaces can ensure that different applications' names do not clash, but does not provide a common basis for exchanging information between different applications.) Any vocabulary that relates to the structure of a CC/PP 2.0 profile must follow this specification. The appendices introduce a simple CC/PP attribute vocabulary that may be used to improve cross-application exchange of capability information, partly based on some earlier IETF work.

CC/PP 2.0 is designed to be broadly compatible with the UAProf 2 specification [UAPROF2] from the OMA (formerly known as WAP Forum), in the same way CC/PP 1.0 used to accommodate UAProf 1.0 profiles.

CC/PP is compatible with IETF media feature sets (CONNEG) [RFC2533] in the sense that all media feature tags and values can be expressed in CC/PP. However, not all CC/PP profiles can be expressed as media feature tags and values, and CC/PP does not attempt to express relationships between attributes.

Although the examples and use to date have been focused on device capabilities, CC/PP can also convey information about user preferences that, used sensibly, should be allow web servers to improve the accessibility of web sites. A fuller discussion of web site accessibility can be found in the Web Content Accessibility Guidelines [WAI].

1.1 Scope and normative elements

CC/PP Structure and Vocabularies 2.0 (abbreviated to CC/PP in the rest of this document) defines a client profile data format, and a framework for incorporating application- and operating environment-specific features. It does not define how the profile is transferred, nor does it specify what CC/PP attributes must be generated or recognized. CC/PP is designed for use as part of a wider application framework. As such, the specification of CC/PP elements that must be supported and those which may be omitted is a matter for a specific application.

There are few protocol assumptions built into the design of CC/PP. Although it is intended to be largely protocol independent, particular consideration has been given to use of CC/PP with HTTP for retrieving Web resources. Appendix F contains some further discussion of CC/PP applications.

This document describes a number of features of CC/PP. Some features form part of the essential structure of CC/PP, for which conformance is REQUIRED (see section 5). Others are features whose use is RECOMMENDED or OPTIONAL. There is also discussion of how new vocabularies should be introduced, directed to CC/PP application designers rather than implementers.

The architecture section does not describe specific features, but indicates general principles that underlie the design of CC/PP. It is not normative but does contain information that should be understood for proper implementation of CC/PP.

The section on CC/PP structure covers two main areas:

The section on CC/PP attribute vocabularies describes some general features of CC/PP attributes and their values. Support for the described formats for simple attribute values is REQUIRED—the actual syntax for any simple CC/PP value is defined by the corresponding attribute specification; such specifications may reference the information provided here. Support for the structured CC/PP attribute formats described, where relevant, is REQUIRED.

Support is not required for any specific vocabulary, but application designers are strongly encouraged to re-use existing vocabularies where possible.

CC/PP applications are not required to support features described in the appendices, but any new attribute vocabularies defined MUST be based on RDF classes and properties defined by the RDF schema in Appendix B (new CC/PP attributes are instances of ccpp:Attribute, new component classes are subclasses of ccpp:Component, etc.).

NOTE: The reason for requiring new vocabularies to be based on the CC/PP schema is so that schema-aware applications can include CC/PP profile data along with other RDF data. Having new vocabulary terms based on the CC/PP schema means that they are clearly identifiable as part of a CC/PP profile when RDF data from multiple sources is combined. This requirement does not affect stand-alone CC/PP profile processors, but the real value of using RDF here will be in the longer term, allowing data from multiple sources (e.g. document, security and privacy related information) to be combined and processed by more general purpose handlers.

1.2 Structure of this document

The remainder of this section covers terminology, conventions and notations used in this document.

Section 2, CC/PP architecture, provides an overview of the CC/PP profile structure and use of XML namespaces.

Section 3, CC/PP structure, describes the structure of a CC/PP profile, and introduces the RDF elements that are used to create the essential CC/PP elements.

Section 4, Attribute vocabularies, describes how attributes are used in a CC/PP profile, and presents the recommended structure of CC/PP elements used to describe specific features.

The appendices contain additional supporting material that is not essential to construct a valid CC/PP profile, but which provides additional background information useful for understanding CC/PP, or defining attribute vocabularies for specific applications.

1.3 Document conventions

1.3.1 Terminology

See CC/PP terminology and abbreviations in Appendix A of this document.

The term "CC/PP attribute" is used here to refer to a specific capability or characteristic of a client (or other system) that appears in a CC/PP profile. The term "feature" refers to a client capability or characteristic that may or may not be the basis of a CC/PP attribute. The term "attribute name" is used to indicate an RDF property name used to identify a CC/PP attribute.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

1.3.2 RDF graph notation

The underlying structure of RDF is a directed labeled graph. For communication between computer systems, RDF uses a serialization in XML to represent these graphs. This XML notation is rather bulky and difficult for human discourse, so a more visual notation, based on the RDF Primer [RDFPRIMER], is used here for describing RDF graph structures.

2. CC/PP architecture

This section is not normative, but provides an overview of the features of CC/PP.

2.1 CC/PP profile structure

A CC/PP profile is broadly constructed as a 2-level hierarchy:

2.1.1 Profile components

The initial branches of the CC/PP profile tree describe major components of the client. Examples of major components are:

A simple, graphical representation of the bottom of a CC/PP tree based on three components (TerminalHardware, TerminalSoftware and TerminalBrowser) would be:

CC/PP profile components
Figure 2-1a: CC/PP profile components

The corresponding XML might look like this:

Figure 2-1b: CC/PP profile components in XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:example="http://www.example.com/schema#">

  <rdf:Description rdf:about="http://www.example.com/profile#MyProfile">
    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile"/>

    <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>

NOTE: RDF/XML [RDFXML] can allow different but semantically equivalent syntaxes, to be used in CC/PP 2.0 conforming profiles. Please refer to Chapter 2.13 of the RDF Primer [RDFPRIMER] to learn more about syntactical abbreviations of RDF/XML using typed nodes.

Editor's note: this suggests we use the full RDF/XML simplification capabilities, rather than a subset of the XML syntax (shown in this document).

2.1.2 Component attributes

A CC/PP profile describes client capabilities and preferences in terms of a number of "CC/PP attributes" for each component.

The description of each component is a sub-tree whose branches are the capabilities or preferences associated with that component. Though RDF makes modeling a wide range of data structures possible, including arbitrary graphs, complex data models are usually best avoided for profile attribute values. A capability can often be described using a small number of CC/PP attributes, each having a simple, atomic value. Where more complex values are needed, these can be constructed as RDF subgraphs. One useful case for complex attribute values is to represent alternative values; e.g. a browser may support multiple versions of HTML. A hypothetical profile might look like this:

Complete CC/PP profile example
Figure 2-2a: Complete CC/PP profile example

The corresponding XML might look like this:

Figure 2-2b: Complete CC/PP profile example in XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:ex="http://www.example.com/schema#">

  <rdf:Description
      rdf:about="http://www.example.com/profile#MyProfile">
    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile" />

    <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>

2.1.3 Defaults

The attributes of a component can be included directly, as in the previous example, or may be specified by reference to a default profile, which may be stored separately and accessed using its specified URI.

This use of an externally defined default profile is somewhat similar to the idea of dynamic inheritance. It makes possible some important optimizations. As a separate document, it can reside at a separate location and it can be separately cached. This is particularly useful in wireless environments such as cellular networks, where the profiles may be large and the client link slow and expensive. Using default values, only a small part of the overall profile is sent over the wireless network.

Default values for a component of a CC/PP profile are indicated by a ccpp:defaults arc from the component concerned to a component that describes the default values.

CC/PP profile using defaults
Figure 2-3a: CC/PP profile using defaults

The corresponding XML might look like this:

Figure 2-3b: CC/PP profile using defaults in XML
Device profile referencing defaults:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:ex="http://www.example.com/schema#">

  <rdf:Description
      rdf:about="http://www.example.com/profile#MyProfile">
    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile" />

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profile#TerminalHardware">
        <rdf:type
            rdf:resource="http://www.example.com/schema#HardwarePlatform" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/hardwareProfile#HWDefault" />
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profile#TerminalSoftware">
        <rdf:type
            rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/softwareProfile#SWDefault" />
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profile#TerminalBrowser">
        <rdf:type
            rdf:resource="http://www.example.com/schema#BrowserUA" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/terminalProfile#UADefault" />
      </rdf:Description>
    </ccpp:component>

  </rdf:Description>
</rdf:RDF>
Defaults for HardwarePlatform:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/hardwareProfile#HWDefault">
    <rdf:type
        rdf:resource="http://www.example.com/schema#HardwarePlatform" />
    <ex:displayWidth>320</ex:displayWidth>
    <ex:displayHeight>200</ex:displayHeight>
  </rdf:Description>
</rdf:RDF>
Defaults for SoftwarePlatform:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/softwareProfile#SWDefault">
    <rdf:type
        rdf:resource="http://www.example.com/schema#SoftwarePlatform" />
    <ex:name>EPOC</ex:name>
    <ex:version>2.0</ex:version>
    <ex:vendor>Symbian</ex:vendor>
  </rdf:Description>
</rdf:RDF>
Defaults for BrowserUA:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/terminalProfile#UADefault">
    <rdf:type
        rdf:resource="http://www.example.com/schema#BrowserUA" />
    <ex:name>Mozilla</ex:name>
    <ex:version>5.0</ex:version>
    <ex:vendor>Symbian</ex:vendor>
    <ex:htmlVersionsSupported>
      <rdf:Bag>
        <rdf:_1>3.2</rdf:_1>
        <rdf:_2>4.0</rdf:_2>
      </rdf:Bag>
    </ex:htmlVersionsSupported>
  </rdf:Description>
</rdf:RDF>

If a given attribute value is applied directly to a component resource, and also appears on a resource referenced by the ccpp:defaults property, the directly applied value takes precedence:

Overriding a default value
Figure 2-4a: Overriding a default value

In this example, the default component indicates 16 Mb of memory, but this value is overridden by the memoryMb property applied directly to the profile component. Thus, in this profile, the memoryMb attribute has a value of 32.

The corresponding XML might look like this:

Figure 2-4b: Overriding a default value in XML
Device profile referencing defaults:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:ex="http://www.example.com/schema#">

  <rdf:Description
      rdf:about="http://www.example.com/profile#MyProfile">
    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile" />

    <ccpp:component>
      <rdf:Description
          rdf:about="http://www.example.com/profile#TerminalHardware">
        <rdf:type
            rdf:resource="http://www.example.com/schema#HardwarePlatform" />
        <ccpp:defaults
            rdf:resource="http://www.example.com/hardwareProfile#HWDefault" />
        <ex:memoryMb>32</ex:memoryMb>
      </rdf:Description>
    </ccpp:component>

  </rdf:Description>
</rdf:RDF>
Defaults for HardwarePlatform:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://www.example.com/schema#">
  <rdf:Description
      rdf:about="http://www.example.com/hardwareProfile#HWDefault">
    <rdf:type
        rdf:resource="http://www.example.com/schema#HardwarePlatform" />
    <ex:displayWidth>320</ex:displayWidth>
    <ex:displayHeight>200</ex:displayHeight>
    <ex:memoryMb>16</ex:memoryMb>
  </rdf:Description>
</rdf:RDF>

A resource indicated by a default property may appear in a separate document, in which case an absolute URI reference should be specified for the default resource. In such cases, the URI part of the default resource identifier (i.e. not including the fragment identifier part) is used to retrieve an RDF document containing the default resource description. Thus, if the default resource is named http://example.com/DeviceProfile#HardwarePlatform, the URI http://example.com/DeviceProfile is used to retrieve an RDF document, and a resource within that document having the local identifier #HardwarePlatform is taken as the default resource. (Such a resource might be defined within the target document using "about='http://example.com/DeviceProfile#HardwarePlatform'" or "ID='HardwarePlatform'". See also section 3.5.)

NOTE: Individual applications may allow relative URIs to be used. Those that do should specify exactly how the corresponding RDF document is located.

2.2 Extensibility and namespaces

CC/PP is extended primarily through the introduction of new attribute vocabularies.

Any application or operational environment that uses CC/PP may define its own vocabulary, but wider interoperability is enhanced if vocabularies are defined that can be used more generally; e.g. a standard extension vocabulary for imaging devices, or voice messaging devices, or wireless access devices, etc. Accordingly, this specification defines a small core vocabulary of features that are applicable to range of print and display agents whose use, where appropriate, is strongly recommended. This core vocabulary is based on IETF specification RFC2534 [RFC2534], and serves as an example of how CC/PP attribute vocabularies may be defined. Another such example is the OMA UAProf 2.0 specification [UAPROF2].

Any CC/PP expression can use terms drawn from an arbitrary number of different vocabularies, so there is no restriction caused by re-using terms from an existing vocabulary rather then defining new names to identify the same information. Each vocabulary is associated with an XML namespace, as are the names that describe the underlying RDF and CC/PP structures.

XML namespaces [XMLNAMESPACES] define a notation for associating convenient name forms with arbitrary URIs. The RDF graph syntax does not specifically employ namespaces, but XML serializations of an RDF graph do. We also use namespace prefixes when presenting RDF in the graph notation described above.

The CC/PP framework uses the XML namespace mechanism to create identifying URIs for RDF core elements, CC/PP structural elements and CC/PP attribute vocabularies. Consider the following namespace declaration example:

Figure 2-7: Example namespace declarations
<?xml version="1.0"?>
<RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
     xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">

The first namespace declaration is for RDF usage. The second declaration names the CC/PP 2.0 core structural vocabulary, which includes "component", "defaults" and other properties that are intrinsic to the CC/PP framework. The third namespace declaration names a component CC/PP properties vocabulary.

NOTE: Remember that the namespace prefixes are quite arbitrary: applications MUST NOT assume that the prefix rdf: refers to the RDF vocabulary, or that ccpp: refers to the intrinsic CC/PP vocabulary, etc. It is the URI to which a namespace prefix is bound that matters.

NOTE: Although namespace names are identified by URI references, there is no requirement that a schema be available at that URI. In the above example, the UAProf namespace name is "http://www.wapforum.org/UAPROF/ccppschema-20000405#" yet there is no schema at that URI. It is generally preferred practice that a corresponding schema exists at the URI used to identify a namespace, but this is not a requirement and CC/PP applications MUST NOT assume that such a schema will exist.

The use of multiple component property vocabularies is allowed and encouraged. Different user communities and application domains (OMA, ETSI, MExE, IETF CONNEG, etc.) may define their own property vocabularies. This is an important mechanism for providing support for the needs of those communities.

The following namespaces are introduced by the CC/PP 2.0 framework:

http://www.w3.org/2006/09/20-ccpp-schema#

Normative RDF schema defining class declarations for CC/PP 2.0, and core structural properties (listed in Appendix B.3).
http://www.w3.org/2006/09/20-ccpp-client#
Example but non-normative vocabulary for describing simple client capabilities, with particular relevance to print and display clients (listed in Appendix C).

3. CC/PP structure

The general structure of a CC/PP client profile is a two-level tree: components and attributes, with provision for each component to reference an externally defined set of default attribute values.

3.1 Components

A CC/PP profile contains one or more components, and each component contains one or more attributes. Each component is represented by a resource of type ccpp:Component (or some RDFS subclass thereof), and related to the client profile resource by a ccpp:component property. Here, the ccpp namespace is http://www.w3.org/2006/09/20-ccpp-schema#. For compatibility with UAProf, the namespace used to qualify component MAY be a UAProf namespace.

The object of a ccpp:Component resource MAY have an rdf:type property (or equivalent RDF structure) indicating what kind of client component it describes. The example in figure 2-2b is of a profile with an explicit indication of component subtype. However, CC/PP processors MUST be able to handle profiles that do not contain component type indicators. As long as the CC/PP attributes used are all specific to a given component type, a processor will have sufficient information to interpret them properly. No more than one instance of a component type should be present for any given profile resource.

If a CC/PP profile uses any attribute that can appear on different component types, then the type of any component on which such an attribute appears MUST be indicated by an rdf:type property, or equivalent RDF. A CC/PP processor MUST be able to use this type information to disambiguate application of any attribute used.

3.2 Attributes

CC/PP profiles are constructed using RDF [RDF]. The RDF data model represents CC/PP attributes as named properties linking a subject resource to an associated object resource or RDF typed literal value.

To describe client capabilities and preferences, the client being described is a resource whose features are described by labeled graph edges from that resource to corresponding object values. The graph edge labels identify the client feature (CC/PP attribute) being described, and the corresponding object values are the feature values.

RDF statement describing a client attribute
Figure 3-1: RDF statement describing a client attribute

CC/PP attribute labels are represented by XML name values (per XML specification [XML], section 2.3), which may include a namespace prefix (i.e. a qualified name, per XML namespaces [XMLNAMESPACES], section 3). When combined with the corresponding namespace or default namespace declaration, each label MUST be mapped to a URI. Thus, CC/PP attribute names are URIs, with XML namespace syntax used to avoid some of the RDF expressions becoming too cumbersome.

Attribute values may be of simple or structured data types.

Simple data types are discussed in the section 4.1.1. Each basic data type may support a range of tests that can be used in the process of determining the suitability of different resource variants for presentation by a client; e.g. equality, compatibility, less-than, greater-than, etc.

Structured data types are supported through the use of specific RDF properties that join simple RDF values into composites. Specific CC/PP semantics for RDF properties used in this way are discussed in the section 4.1.2.

3.3 Defaults

Each component of a client profile may indicate a single separate resource that in turn indicates a subordinate collection of default attribute values. This collection of default values can be a separate RDF document that is named via a URI, or can appear in the same document as the client profile (though, in practice, there is probably little value in defaults in the same document). If an attribute in the collection of defaults is also present in the main part of the client profile, the non-default value takes precedence. The intent is that a hardware vendor or system supplier may provide default values that are common to a number of systems in a place easily accessible to an origin server, and then use the client profile to specify variations from the common profile. The owner of the product or system operator may be able to add or change options, such as additional memory, that add new capabilities or change the values of some original capabilities.

Default values are referenced by the property ccpp:defaults. This name conforms to the name format recommendations of the RDF syntax specification [RDFXML]. Here, the ccpp namespace is http://www.w3.org/2006/09/20-ccpp-schema#. For compatibility with UAProf, the namespace used to qualify defaults MAY be a UAProf namespace.

Defaults can be encoded inline or as separate documents referred to via URI, but 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:

CC/PP profile using defaults
Figure 3-2a: CC/PP profile using defaults

If a component referenced by ccpp:defaults contains an attribute that is not present on the referencing profile component, then the effect is as if the attribute value in the default component is applied directly to the profile component. For example the profile in Figure 3-2a should be interpreted as describing the same capabilities as shown in Figure 3-2b.

Resolving a CC/PP profile using defaults
Figure 3-2b: Resolving a CC/PP profile using defaults

And here is the XML serialization corresponding to Figure 3-2a, 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. Please also note that, while Figure 3-2a and Figure 3-2b are equivalent in the context of CC/PP, these two graphs have very different RDF representations.

Figure 3-2c: CC/PP profile using inline defaults, in XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:prf="http://example.com/Schema#">

  <rdf:Description rdf:about="http://example.com/MyProfile">

    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile"/>

    <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:_1>3.2</rdf:_1>
                <rdf:_2>4.0</rdf:_2>
              </rdf:Bag>
            </prf:htmlVersionsSupported>
          </rdf:Description>
        </ccpp:defaults>
        <prf:htmlVersionsSupported>
          <rdf:Bag>
            <rdf:_1>2.0</rdf:_1>
            <rdf:_2>3.2</rdf:_2>
            <rdf:_3>4.0</rdf:_3>
          </rdf:Bag>
        </prf:htmlVersionsSupported>
      </rdf:Description>
    </ccpp:component>
  </rdf:Description>
</rdf:RDF>

Inline defaults are logically equivalent to defaults contained in an external referenced document, and such external documents would be a normal way of providing default values. The following is the XML serialization of the same profile with references to externally defined defaults:

Figure 3-3: CC/PP profile referencing externally defined defaults, in XML
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:prf="http://example.com/Schema#">

  <rdf:Description rdf:about="http://example.com/MyProfile">

    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile"/>

    <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:_1>2.0</rdf:_1>
            <rdf:_2>3.2</rdf:_2>
            <rdf:_3>4.0</rdf:_3>
          </rdf:Bag>
        </prf:htmlVersionsSupported>
      </rdf:Description>
    </ccpp:component>
  </rdf:Description>
</rdf:RDF>

Each external defaults resource is a separate RDF document referenced by a URI.

NOTE: A default document uses a <rdf:Description> element as its root node. The <rdf:Description> is named using an rdf:about whose value is a URI. This URI MUST correspond to the value of the rdf:resource XML attribute in the <ccpp:defaults> element in the referencing document. (The default component does not need to be identified when it occurs inline, as in the first example above.) In the examples of default documents below, the URIs of the external default values documents are used. However the default resource URI does not have to be the document URI, as long as the URI is uniquely identified, the same URI is used in both the source document and the external default values document, and there is some way for the processing software to locate and retrieve the document containing the default resource.

Examples of default documents referenced by the previous example are as follows:

Figure 3-4: External HardwarePlatform default values
Document: http://example.com/HWDefault
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://example.com/Schema#">
   <rdf:Description rdf:about="http://example.com/HWDefault">
     <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform"/>
     <prf:cpu>PPC</prf:cpu>
     <prf:displayWidth>320</prf:displayWidth>
     <prf:displayHeight>200</prf:displayHeight>
   </rdf:Description>
</rdf:RDF>

 

Figure 3-5: External SoftwarePlatform default values
Document: http://example.com/SWDefault
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://example.com/Schema#">
   <rdf:Description rdf:about="http://example.com/SWDefault">
     <rdf:type rdf:resource="http://example.com/Schema#SoftwarePlatform"/>
     <prf:name>EPOC</prf:name>
     <prf:vendor>Symbian</prf:vendor>
     <prf:version>2.0</prf:version>
   </rdf:Description>
</rdf:RDF>

 

Figure 3-6: External BrowserUA default values
Document: http://example.com/UADefault
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://example.com/Schema#">
  <rdf:Description rdf:about="http://example.com/UADefault">
    <rdf:type rdf:resource="http://example.com/Schema#BrowserUA"/>
    <prf:name>Mozilla</prf:name>
    <prf:vendor>Symbian</prf:vendor>
    <prf:version>5.0</prf:version>
    <prf:htmlVersionsSupported>
      <rdf:Bag>
        <rdf:li>3.2</rdf:li>
        <rdf:li>4.0</rdf:li>
      </rdf:Bag>
    </prf:htmlVersionsSupported>
  </rdf:Description>
</rdf:RDF>

Editor's note: from an RDF point of view, there is no difference between figure 3-2c on the one hand, and 3-3 merged with 3-4~3-6 on the other. We may consider, if this chapter is more misleading than helpful, remove it, or refer to the RDF Primer instead.

3.4 Distinguishing profile structure from attributes

CC/PP uses namespaces to distinguish the vocabulary associated with the structure (e.g. ccpp:component) from vocabularies associated with applications (e.g. TerminalHardware, display).

In this example we use the namespace "http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#", associated with prefix "prf:", to describe properties that are not defined in the CC/PP or RDF namespaces:

Figure 3-7: XML serialization of CC/PP profile, with namespaces
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ccpp="http://www.w3.org/2006/09/20-ccpp-schema#"
         xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#">

  <rdf:Description rdf:about="http://example.com/MyProfile">

    <rdf:type rdf:resource="http://www.w3.org/2006/09/20-ccpp-schema#Client-profile"/>

    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/TerminalHardware">
        <rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#HardwarePlatform" />
        <prf:CPU>PPC</prf:CPU>
        <prf:ScreenSize>320x200</prf:ScreenSize>
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/TerminalSoftware">
        <rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#SoftwarePlatform" />
        <prf:OSName>EPOC</prf:OSName>
        <prf:OSVendor>Symbian</prf:OSVendor>
        <prf:OSVersion>2.0</prf:OSVersion>
      </rdf:Description>
    </ccpp:component>

    <ccpp:component>
      <rdf:Description rdf:about="http://example.com/Browser">
        <rdf:type rdf:resource="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#BrowserUA" />
        <prf:BrowserName>Mozilla</prf:BrowserName>
        <prf:BrowserVersion>5.0</prf:BrowserVersion>
        <prf:HtmlVersion>
          <rdf:Bag>
            <rdf:li>3.2</rdf:li>
            <rdf:li>4.0</rdf:li>
          </rdf:Bag>
        </prf:HtmlVersion>
      </rdf:Description>
    </ccpp:component>
  </rdf:Description>
</rdf:RDF>

All RDF resources that relate to the overall structure of CC/PP are defined in the ccpp: namespace, and have associated schema properties that allow them to be distinguished from attribute vocabulary or other RDF statements by a schema-aware processor.

3.5 Notes on RDF usage

This specification can use either "rdf:about" and/or the association of "rdf:ID" and "xml:base", to specify the URIs of resources in examples. This ensures that such URIs are absolutely and unambiguously specified.

The values of "rdf:ID" attributes represent URIs which are relative to the value of the xml:base [XMLBASE] if it is mentioned, or relative to the base URI of the document [RDFFRAGMENT] in other cases (i.e. if xml:base is not mentioned). When a document is moved to another location on the web the meaning of the value of an "rdf:ID" attribute changes, unless the base URI is mentioned with xml:base. The meaning is undefined when the RDF is contained in a document with no base URI, e.g. when encapsulated in a message.

The component resources in a profile are instances of components identified in the corresponding schema, which in turn MUST be subclasses of ccpp:Component. They may usefully be identified as such, by means of the rdf:type property whose value matches the name of the component type in the schema.

3.6 RDF graph composition

The RDF statements that make up an RDF graph do not necessarily occur in a single document. For CC/PP, the profile delivered may contain references to RDF subgraphs that are transferred separately, or are retrieved from designated Web resources.

When an external sub-graph is referenced in this way, the effect is equivalent to taking the sets of RDF statement "triples" described by the referencing document and the referenced document, and constructing a new document that describes the union of these sets. (NOTE: implementations are not required to actually construct such a document, just to interpret the RDF statements as they would from a single document.)

This composition of multiple RDF documents presumes that the content of the referenced document is trusted to accurately represent the capabilities that are presented to the sender of some resource data. Accordingly, such composition is restricted to documents describing resources referenced by properties whose intended interpretation embodies such a notion of trust; viz. ccpp:defaults.

4. Attribute vocabularies

4.1 Attribute data

This section describes the basic data types and data structuring options that are available for the values associated with a CC/PP attribute.

All CC/PP attributes must 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 REQUIRED; this specification does not prohibit the use of other valid RDF forms, but provides no guidance for their interpretation. (See also section 1.1 and Appendix F.)

4.1.1 Simple CC/PP attribute data

All simple CC/PP 2.0 attributes are represented by RDF typed literal values [RDFSCHEMA].

RDF representation of a simple value in CC/PP
Figure 4-6: RDF representation of a simple value in CC/PP

See the RDF Primer [RDFPRIMER] for more information on RDF usage.

4.1.2 Complex CC/PP attribute data

In addition to the simple values described above, a CC/PP attribute may have a complex value expressed in the form of a resource with its own collection of RDF properties and associated values. Specific data types represented in this way are:

For more information about those Containers, please refer to Chapter 4.1 of the RDF Primer [RDFPRIMER].

Complex CC/PP attribute data MUST explicitly indicate their base type, in the same way as the type is specified for simple CC/PP attribute data.

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.

4.2 Attribute identifiers

CC/PP attribute names are in the form of a URI. Any CC/PP vocabulary is associated with an XML namespace, which combines a base URI with a local XML element name (or XML attribute name) to yield a URI corresponding to an attribute name. E.g. the namespace URI:

http://www.w3.org/2006/09/20-ccpp-client#

and the core vocabulary name:

type

are combined to yield the attribute name URI reference:

http://www.w3.org/2006/09/20-ccpp-client#type

Anyone can define and publish a CC/PP vocabulary extension (assuming administrative control or allocation of a URI for an XML namespace). For such a vocabulary to be useful, it must be interpreted in the same way by communicating entities. Thus, use of an existing extension vocabulary is encouraged wherever possible; failing this, publication of a new vocabulary definition containing detailed descriptions of the new CC/PP attributes.

Many extension vocabularies will be drawn from existing applications and protocols; e.g. WAP UAProf, IETF media feature registrations, etc. Appendix E surveys some possible sources of additional CC/PP vocabularies.

4.3 RDF vocabulary schema

Attribute names are defined, and associated with an XML namespace, using an RDF schema.

Appendix B to this document contains an RDF schema describing terms for use in CC/PP profiles. Appendix C contains an example Schema describing a CC/PP vocabulary. Appendix D contains recommendations for creating a new vocabulary.

A CC/PP processor is not required to understand and process RDF Schema definitions; it merely needs to understand enough about the CC/PP profile structure and vocabulary used to perform its job. (A schema-aware processor may be able to handle CC/PP profiles in other ways, or in combination with other RDF information, but such behavior is beyond the scope of this specification.)

5. Conformance

This section explains how to make a valid claim that a product conforms to this specification. Anyone may make a claim (e.g., vendors about their own products, third parties about those products, journalists about products, etc.). Claims may be published anywhere (e.g., on the Web or in product documentation). Claimants are solely responsible for their claims. If the subject of the claim (e.g., the software) changes after the date of the claim, the claimant is responsible for updating the claim. Claimants are expected to modify or retract a claim if it may be demonstrated that the claim is not valid. Claimants are encouraged to conform to the most recent specification available.

There are three classes of products of CC/PP:

  1. documents (e.g. a web resource)
  2. producers (e.g. a web client)
  3. consumers (e.g. a web server)

5.1 CC/PP Document Conformance

Documents may exist as resources accessible via a URI, or may be transmitted as data in a message. A document is CC/PP conformant when it meets the following criteria:

  1. The document MUST be valid RDF serialized in XML, and be based on one or more vocabularies derived from the RDF Schema in Appendix B. See section 1.
  2. The document MUST use valid syntax for namespace declarations. See section 2.2.
  3. The profile element MUST contain one or more components. See section 2.1.
  4. Each component in the profile MUST contain one or more attributes. See section 2.1.
  5. The component names MAY be in rdf:about attribute and/or in the conjunction of rdf:ID and xml:base. See section 3.5.
  6. Components MUST be indicated using a ccpp:component property where the namespace used to qualify component is the CC/PP namespace or a UAProf namespace. See section 3.1.
  7. Component names, component types, and attribute names must all refer to different URIs within a profile. See section 3.
  8. If a component type is given as an element name and as an rdf:type element, they MUST refer to the same URI. See section 3.1.
  9. Default references MUST be valid URIs. See section 3.3.
  10. Defaults MUST be indicated using a ccpp:defaults property where the namespace used to qualify defaults is the CC/PP namespace or a UAProf namespace. See section 3.3.
  11. Component attributes MAY contain both a default value and a directly applied value, with the directly applied value taking precedence. See section 3.3.
  12. Components MAY contain inline defaults. See section 3.3.
  13. Components MUST NOT contain both inline and referenced defaults. See section 3.3.
  14. Components MAY reference a default document which does not have an rdf:type. See section 3.3.
  15. Attributes MUST be typed with simple types (see section 4.1.1). In addition, complex attributes MUST also be typed as either sets of values (rdf:Bags), or sequences of values (rdf:Seqs).
  16. A component MUST NOT contain more than one attribute with the same name. See section 3.2.
  17. Attributes of the same name MAY be in different components. See section 3.1.
  18. Profiles MAY use multiple namespaces for attributes. See section 2.2.

Editor's notes: "Default references MUST be valid URIs" is subsumed by "MUST be valid RDF". We may consider removing it.
Same happens for "Profiles MAY use multiple namespaces for attributes".

5.2 CC/PP Producer Conformance

A producer is CC/PP conformant when any CC/PP profile document generated by the producer is a CC/PP conformant document.

5.3 CC/PP Consumer Conformance

A consumer is CC/PP conformant when the consumer accepts any CC/PP conformant document and extracts CC/PP information. Schema-aware processing is not required, and therefore, support for the RDF Schema in Appendix B by CC/PP consumers is OPTIONAL (see section 4.3).

There are two categories of conformance for CC/PP consumers:

  1. Conformant: a CC/PP consumer can claim to be a "CC/PP 2.0 conformant consumer" if it accepts any valid CC/PP 2.0 profile, extracts information from it, and detects possible type mismatches.
  2. Validating: a CC/PP consumer can claim to be a "CC/PP 2.0 conformant validating consumer" if it is conformant and if it rejects all invalid CC/PP 2.0 profiles (including those containing type mismatches).

NOTE: A consumer implementation may be configurable to act as either a conformant consumer or a conformant validating consumer at different times.

5.4 Conformance Claims

5.4.1 Validity

A conformance claim is valid if it is well formed and meets the appropriate conformance criteria for the applicable product class as given above.

5.4.2 Well-formedness

A conformance claim is well-formed if it includes the following information:

  1. the date of the claim
  2. the product class (document, producer, or consumer)
  3. the consumer category (conformant or conformant validating) if applicable
  4. the title and dated URI of this document
  5. the product name (identity), including a version, date, or other identifier that uniquely identifies the product

6. Acknowledgments

This specification is the work of the W3C Device Independence Working Group. It is closely based on earlier work on the CC/PP 1.0 specification. Useful revisions and clarifications were suggested by Art Barstow (Nokia), Bennett Marks (Nokia) and Andreas Schade (IBM).

7. References

7.1 Normative References

[XML]
Extensible Markup Language (XML) 1.0 (Fourth Edition); Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, François Yergeau; World Wide Web Consortium Recommendation 16 August 2006: http://www.w3.org/TR/2006/REC-xml-20060816/.
[XMLNAMESPACES]
Namespaces in XML (Second Edition); Tim Bray, Dave Hollander, Andrew Layman, Richard Tobin; World Wide Web Consortium Recommendation 16 August 2006: http://www.w3.org/TR/2006/REC-xml-names-20060816
[RDF]
RDF/XML Syntax Specification (Revised); Dave Beckett, Brian McBride; W3C Recommendation 10 February 2004: http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
[RDFSCHEMA]
RDF Vocabulary Description Language 1.0: RDF Schema Specification; Brian McBride; World Wide Web Consortium Recommendation 10 February 2004: http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
[RDFXML]
RDF/XML Syntax Specification (Revised); Dave Beckett, Brian McBride; World Wide Web Consortium Recommendation 10 February 2004: http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
[XMLBASE]
XML Base; Jonathan Marsh; World Wide Web Consortium Recommendation 27 June 2001: http://www.w3.org/TR/2001/REC-xmlbase-20010627/

7.2 Informative References

[RFC2506]
RFC 2506: Media Feature Tag Registration Procedure; K. Holtman, A. Mutz, T. Hardie; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2506.txt
[RFC2533]
RFC 2533: A Syntax for Describing Media Feature Sets; G. Klyne; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2533.txt
[CONNEGMATCH]
A revised media feature set matching algorithm; G. Klyne; Internet-Draft, work in progress: draft-klyne-conneg-feature-match-02.txt
[RFC2534]
RFC 2534: Media Features for Display, Print, and Fax; L. Masinter, D. Wing, A. Mutz, K. Holtman; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2534.txt
[UAPROF2]
User Agent Profile version 2.0 (2006); OMA specification; available at http://www.openmobilealliance.org/release_program/docs/UAProf/V2_0-20060206-A/OMA-TS-UAProf-V2_0-20060206-A.pdf
[DATASTRUCTURE]
Notes on Data Structuring; C. A. R. Hoare; in Structured Programming, Academic Press, 1972. ISBN 0-12-2000556-2.
[XMLSCHEMA-0]
XML Schema. Part 0: Primer; David C. Fallside; World Wide Web Consortium Recommendation 28 October 2004: http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/
[XMLSCHEMA-1]
XML Schema. Part 1: Structures; Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn; World Wide Web Consortium Recommendation 28 October 2004: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
[XMLSCHEMA-2]
XML Schema. Part 2: Datatypes; Paul V. Biron, Ashok Malhotra; World Wide Web Consortium Recommendation 28 October 2004: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
[SEMANTICTOOLBOX]
The Semantic Toolbox: Building Semantics on top of XML-RDF; Tim Berners-Lee; http://www.w3.org/DesignIssues/Toolbox.html
[RFC2531]
RFC 2531: Content Feature Schema for Internet Fax; G. Klyne, L. McIntyre; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2531.txt
[TIFF]
TIFF (Tagged Image File Format) 6.0 Specification; Adobe Systems Inc.; http://partners.adobe.com/asn/developer/pdfs/tn/TIFF6.pdf
[RFC2301]
RFC 2301: File Format for Internet Fax; L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2301.txt
[MULTIMEDIA]
Multimedia Programming Interface and Data Specifications 1.0 (contains WAVE file format); IBM Corporation and Microsoft Corporation
[RFC2361]
RFC 2361: WAVE and AVI Codec Registries; E. Fleischman; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2361.txt
[MPEG]
MPEG-4 Overview - (V.14 - Geneva Version), ISO/IEC JTC1/SC29/WG11 N3444 Rob Koenen Overview of the MPEG-4 Standard: http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm
[PWG]
Printer Working Group; http://www.pwg.org
[RFC2566]
RFC 2566: Internet Printing Protocol/1.0: Model and Semantics; R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2566.txt
[RFC2119]
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels; S. Bradner; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2119.txt.
[MPEG-7]
MPEG-7 Overview (version 8.0), ISO/IEC JTC1/SC29/WG11 N3445 José M. Martínez (UPM-GTI, ES) Overview of the MPEG-7 Standard: http://mpeg.telecomitalialab.com/standards/mpeg-7/mpeg-7.htm
[RFC2277]
RFC 2277: IETF Policy on Character Sets and Languages; H. Alvestrand; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2277.txt
[RFC2396]
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax; T. Berners-Lee, R. Fielding, L. Masinter; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2396.txt
[RFC2278]
RFC 2278: IANA Charset Registration Procedures; N. Freed, J. Postel; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2278.txt
[CCPP1]
Composite Capabilities/Preference Profiles: Structure and Vocabularies 1.0; Graham Klyne, Franklin Reynolds, Chris Woodrow, Hidetaka Ohto, Johan Hjelm, Mark H Butler, Luu Tran; World Wide Web Consortium Recommendation 15 January 2004: http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/
[RFC2616]
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1; R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee; IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2616.txt
[CONCEPTUAL]
Conceptual Structures: Information Processing in Mind and Machine; John F. Sowa; Addison Wesley, Reading MA, 1984.
[KNOWLEDGE]
Knowledge Representation; John F. Sowa; Brooks/Cole, 2000. ISBN: 0-534-94965-7
[RDFFRAGMENT]
Re: How to address RDF fragment; Ralph R Swick; Message to World Wide Web Consortium RDF-comments mailing list: http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html.
[CCPPEX]
CC/PP exchange protocol; Hidetaka Ohto, Johan Hjelm; World Wide Web Consortium Note 24 June 1999: http://www.w3.org/1999/06/NOTE-CCPPexchange-19990624
[WAI]
Web Content Accessibility Guidelines 2.0; Wendy Chisholm, Jason White, Gregg Vanderheiden, Ben Caldwell; World Wide Web Consortium Working Draft 27 April 2006: http://www.w3.org/TR/2006/WD-WCAG20-20060427/
[RDFPRIMER]
RDF Primer; Frank Manola, Eric Miller; World Wide Web Consortium Working Draft 10 February 2004: http://www.w3.org/TR/2004/REC-rdf-primer-20040210/

Appendix A: Terminology and abbreviations

A.1 Terminology

This appendix is INFORMATIVE.

Attribute, or CC/PP attribute
A CC/PP attribute refers to the data elements describing the profile and is denoted as an RDF property. Each CC/PP attribute is associated with a value or a list of values or an RDF resource. NOTE: this is quite distinct from an XML attribute; except where the meaning obvious in context, the term "CC/PP attribute" is generally used to emphasize this usage.
CC/PP Processor
A CC/PP processor transforms a CC/PP document from its RDF format into some other format. A CC/PP processor understands CC/PP syntax and structure, including "defaults", but it does not understand application semantics associated with CC/PP attributes of CC/PP components.
CC/PP Repository
A server that stores the user agent profile or profile segments persistently in a form that may be referenced by and incorporated into a profile. A CC/PP repository is typically a Web server that provides CC/PP profiles or profile segments in response to HTTP requests.
Cacheable
A data resource is said to be "cacheable" if the data resource contains a property that allows a server to determine whether the cached resource matches a request for a similar resource.
Cache
A storage area used by a server or proxy to store data resources that have been retrieved or created in response to a request. When a new request for a "cached" data resource is received, the server or proxy can respond with the cached version instead of retrieving or creating a new copy.
Capability
An attribute of a sender or receiver (often the receiver) which indicates an ability to generate or process a particular type of message content. See also "CC/PP Attributes".
Client
An entity that is the original compositor of a CC/PP profile.
Confidentiality
Protecting the content of a message from unauthorized disclosure.
Content Generation
For the purpose of this specification, "content generation" refers to generating content appropriate to the user agent profile of the request by using the user agent profile as input to a dynamic content generation engine. The XSL and style sheets of the document are used to tailor the document to the user agent profile of the request.
Content Negotiation
The mechanism for selecting the appropriate representation when servicing a request. The representation of entities in any response can be negotiated (including error responses).
Content Selection
For the purpose of this specification, "content selection" refers to selecting an appropriate document from a list of possible choices or variants by matching the document profile with the user agent profile of the request.
Content Provider
A server that originates content in response to a request.
Data Resource
A data object that can be transferred across a network. Data resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways.
Document
For the purpose of this specification, "document" refers to content supplied in response to a request. Using this definition, a "document" may be a collection of smaller "documents", which in turn is a part of a greater "document".
Document Profile
Document profiles offer a means to characterize the features appropriate to given categories of user agents. For instance, one profile might include support for style sheets, vector graphics and scripting, while another might be restricted to the tags in HTML 3.2. Document profiles can be used by servers to select between document variants developed for different user agent categories. They can be used to determine what transformations to apply when such variants are not available. Content developers can use document profiles to ensure that their Web sites will be rendered as intended.
Dynamic Content
Content that is generated in response to a request. This may be used for content that depends on changing environmental factors such as time (e.g., stock quotes) or place (e.g., nearby gas stations)
Feature
Functional property of a device or entity.
Gateway
Software that is capable of bridging disparate network protocols. For the purposes of this specification, "gateway" refers to protocol bridging functionality, which may exist in a stand-alone gateway or may be co-located with a proxy or origin server.
Hint
A suggestion or preference for a particular option. While this option is strongly recommended, its use is not required.
Machine Understandable
Data that is described with tags that associate a meaning to the data (i.e., an "author" tag would describe the author of the document), allowing data to be searched or combined and not just displayed.
Namespace
A qualifier added to an XML tag to ensure uniqueness among XML elements.
Negotiate Content
Message content that has been selected by content negotiation.
Negotiation Metadata
Information which is exchanged between the sender and the receiver of a message by content negotiation in order to determine the variant which should be transferred.
Non-variant Content
When the form/format of the content being sent does not depend on receiver's capabilities and/or preferences
Origin Server
Software that can respond to requests by delivering appropriate content or error messages. The origin server may receive requests via either WSP or HTTP. Application programs executing on the origin server deliver content that is tailored in accordance with the CC/PP that can be found within the provided Profile. For the purpose of this specification, "origin server" refers to content generation capabilities, which may physically exist in a stand-alone Web server or may be co-located with a proxy or gateway.
Preference
An attribute of a sender or receiver (often the receiver) which indicates a preference to generate or process one particular type of message content over another, even if both are possible.
Privacy
Preventing the unintended or unauthorized disclosure of information about a person. Such information may be contained within a message, but may also be inferred from patterns of communication; e.g. when communications happen, the types of resource accessed, the parties with whom communication occurs, etc.
Profile
An instance of the schema that describe capabilities for a specific device and network. A profile need not have all the attributes identified in the vocabulary/schema.
Proxy
Software that receives HTTP requests and forwards that request toward the origin server (possibly by way of an upstream proxy) using HTTP. The proxy receives the response from the origin server and forwards it to the requesting client. In providing its forwarding functions, the proxy may modify either the request or response or provide other value-added functions. For the purposes of this specification, "proxy" refers to request/response forwarding functionality, which may exist in a stand-alone HTTP proxy or may be co-located with a gateway or origin server.
RDF Resource
An object or element being described by RDF expressions is a resource. An RDF resource is typically identified by a URI.
Receiver
A system component (device or program) which receives a message.
Schema, RDF Schema
An RDF Schema denotes resources which constitute the particular unchanging versions of an RDF vocabulary at any point in time. It is used to provide information (such as organization and relationship) about the interpretation of the statements in an RDF data model. It does not include the values associated with the attributes.
Security
Describes a set of procedures applied to data communications to ensure that information is transferred exactly as the sender and receiver intend, and in no other way. Security generally breaks down into Integrity, Authentication, Confidentiality and Privacy.
Sender
A system component (device or program) which transmits a message.
User
An individual or group of individuals acting as a single entity. The user is further qualified as an entity who uses a device to request content and/or resource from a server.
User agent
A program, such as a browser, running on the device that acts on a user's behalf. Users may use different user agents at different times.
User agent profile
Capabilities and preference information pertaining to the capabilities of the device, the operating and network environment, and users personal preferences for receiving content and/or resource.
Variant
One of several possible representations of a data resource.
Variant Content
When the form/format of the content being sent depends on receiver's capabilities and/or preferences
Vocabulary
A collection of attributes that adequately describe the CC/PP. A vocabulary is associated with a schema.

A.2 Abbreviations

CC/PP Composite Capabilities/Preferences Profile
CC/PPex CC/PP Exchange Protocol
CONNEG Content Negotiation Working Group in the IETF
ER Entity-Relationship
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
HTTPex HTTP Extension Framework
IANA Internet Assigned Numbers Authority
IETF Internet Engineering Task Force
IOTP Internet Open Trading Protocol
LDAP Lightweight Directory Access Protocol
OMA Open Mobile Alliance
OTA Over The Air, i.e. in the radio network
RDF Resource Description Framework
RFC Request For Comments
TBD To Be Determined
TCP/IP Transmission Control Protocol/Internet Protocol
UAProf WAP User Agent Profile
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WBXML WAP Binary XML
WML Wireless Markup Language
WSP Wireless Session Protocol
XHTML Extensible HyperText Markup Language
XSL Extensible Stylesheet Language
XML Extensible Markup Language

Appendix B: RDF schema for structure

This appendix is NORMATIVE, but support by CC/PP processors is OPTIONAL.

B.1 Summary of CC/PP class hierarchy

Figure B-1: CC/PP class hierarchy
rdfs:Resource
    ccpp:Profile            {Profile deliverable to origin server}
    ccpp:Component

rdfs:Literal                {A literal value for CC/PP attribute}


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}

B.2 Summary of CC/PP properties

Structural properties (instances of ccpp:Structure)

Figure B-2: CC/PP structural properties
ccpp:component      Domain=ccpp:Profile,         Range=ccpp:Component
ccpp:defaults       Domain=ccpp:Component,       Range=ccpp:Component

B.3 RDF Schema

CC/PP core and class structure:

(Schema URI: http://www.w3.org/2006/09/20-ccpp-schema)

Figure B-3: RDF schema for CC/PP classes and core properties
<?xml version='1.0'?>

<!DOCTYPE rdf:RDF [
  <!ENTITY ns-rdf  'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
  <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
  <!ENTITY ns-ccpp 'http://www.w3.org/2006/09/20-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;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>

  <rdfs:Class rdf:about='&ns-ccpp;Client-profile'>
    <rdfs:label xml:lang="en">CC/PP Client Profile</rdfs:label>
    <rdfs:comment xml:lang="en">
      All CC/PP 2.0 client profiles must be of this type.
    </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>

  
</rdf:RDF>

Editor's note: We could model these properties using subproperties; or stay with a structure that is close to CC/PP 1.0.

Appendix C: CC/PP attribute vocabulary for print and display

The appendix is OPTIONAL and INFORMATIVE.

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 [RFC2534].

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 http://www.w3.org/2006/09/20-ccpp-client. (These attributes apply to presented capabilities of the client rather than to a specific internal component or aspect of a client system.)

deviceIdentifier:
(Value data type: String) A URI that serves as an identifier of the client device or user agent type.
type:
(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.
schema:
(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 [XML], XML Schema [XMLSCHEMA-1], RDF Schema [RDFSCHEMA] or any other applicable document structure that can be identified by a URI. A Schema value refines any acceptable document type indicated by the Type attribute, but its meaning must not depend on the value of Type. Typically, this will be used to indicate specific XML DTDs or schema that are recognized within text/xml or application/xml document types.
charWidth:
(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').
charHeight:
(Value data type: Integer) For a text display device (type="text/*"), the number of lines of text that can be displayed (i.e. the display height in characters).
charset:
(Value data type: set of Strings, per [RFC2278]) For a text handling device, a character encoding that can be processed (values per MIME 'charset' parameter on content-type "text/*"). NOTE: 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.
pix-x:
(Value data type: Integer) For an image display device (type="image/*"), the number of horizontal pixels that can be displayed.
pix-y:
(Value data type: Integer) For an image display device (type="image/*"), the number of vertical pixels that can be displayed.
color:
(Value data type: token, per [RFC2534]) For text and image display devices, an indication of the color capabilities (per RFC 2534 [RFC2534], possible values are "binary", "grey", "limited", "mapped" and "full"). NOTE: the color 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.

Client attribute properties (instances of ccpp:Attribute)

Figure C-1: CC/PP client vocabulary properties
ccpp-client:deviceIdentifier Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#anyURI
ccpp-client:type             Domain=ccpp:Component,   Range=rdf:Bag,
                                                      Range=http://www.w3.org/2001/XMLSchema#string
ccpp-client:schema           Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#anyURI
ccpp-client:charWidth        Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#integer
ccpp-client:charHeight       Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#integer
ccpp-client:charset          Domain=ccpp:Component,   Range=rdf:Bag,
                                                      Range=http://www.w3.org/2001/XMLSchema#token
ccpp-client:pix-x            Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#integer
ccpp-client:pix-y            Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#integer
ccpp-client:color            Domain=ccpp:Component,   Range=http://www.w3.org/2001/XMLSchema#token

Editor's note: We may make the range restriction (XMLSchema#integer instead of rdf-schema#Literal) explicit in the client attribute property definitions too

Schema for client vocabulary

(Schema URI: http://www.w3.org/2006/09/20-ccpp-client)

Figure C-2: RDF schema for client vocabulary
<?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/2006/09/20-ccpp-schema#'>
  <!ENTITY ns-ccpp-client 'http://www.w3.org/2006/09/20-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-rdfs;Literal'/>
    <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-rdfs;Literal'/>
    <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-rdfs;Literal'/>
    <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-rdfs;Literal'/>
    <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-rdfs;Literal'/>
    <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-rdfs;Literal'/>
    <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-rdfs;Literal'/>
    <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>

Appendix D: Recommendations for creating a vocabulary

This appendix in INFORMATIVE.

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.

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.

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.

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 Appendix C of this document).

D.1 Basic format for all vocabulary items

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.

All properties used as CC/PP attributes must be instances of the class ccpp:Attribute, which itself is a subclass of rdf:Property. (That is, the schema defining CC/PP attribute properties should define them as instances of ccpp:Attribute. 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.)

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 ccpp:Component. New ccpp:Component based classes may be introduced for new types of attribute vocabulary, but it is strongly recommended that an existing ccpp:Component type be used if one is applicable.

NOTE: 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.

D.2 Use of XML namespaces

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.)

NOTE: 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.

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, a:foo and b:foo name quite distinct attributes as long as the prefixes a: and b: are associated with different namespace URIs.

D.3 Principles for defining new attributes

D.3.1 If possible, reuse existing vocabularies

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.

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.

D.3.2 Attribute value type and interpretation

Attribute definitions must indicate the type of the associated value, and its interpretation should be documented. Ultimately it is a matter for agreement between generating and receiving applications how any particular attribute value is to be interpreted.

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.

D.3.3 Interpretation not dependent on other attribute values

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.)

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).

D.3.4 Attribute naming conventions

Attributes are RDF properties. The RDF Model and Syntax document [RDF], 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).

RDF class names used in CC/PP profiles preferably begin with an uppercase letter.

D.3.5 Attributes should have specific applicability

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.

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.

D.4 Protocol interactions

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 charset and the HTTP accept-charset: 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.

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.

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.

Appendix E: Review of applicable vocabularies

This appendix is INFORMATIVE.

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.

E.1 IETF media feature registration (CONNEG)

The IETF has defined an IANA registry for media feature tags [RFC2506] and a syntax [RFC2533] for relational-style expressions using these to describe client and server media features. A small common vocabulary has been defined [RFC2534], 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 [RFC2531].

RFC 2506 [RFC2506] defines three kinds of media feature tags:

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.

Unregistered feature tags may be used in CC/PP expressions by stripping off the leading 'u.' and taking the resulting URI.

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).

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. 'pix-x<=640') and attribute values that appear in certain combinations (e.g. 'pix-x=640' AND 'pix-y=480' OR 'pix-x=800' AND 'pix-y=600'). Future work may define such mechanisms.

E.2 WAP UAProf

UAProf 2.0 [UAPROF2] is an OMA specification that is designed to allow wireless mobile devices to declare their capabilities to data servers and other network components.

The design of UAProf is also based on RDF. As such, its vocabulary elements use the same basic format that is used for CC/PP.

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.

Valid UAProf 2 profiles are also valid CC/PP 2 profiles.

E.3 TIFF

TIFF is a raster image encapsulation file format developed and maintained by Adobe Systems [TIFF]. It is also the basis for the standard file format for Internet Fax [RFC2301].

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 [RFC2531]; these might best be referenced using URIs based on their CONNEG tag names.

E.4 WAVE

WAVE is an encapsulation format for audio data, developed and maintained by Microsoft [MULTIMEDIA].

There is a registry of WAVE-supported audio codecs that might be used as CC/PP attributes [RFC2361].

E.5 MPEG-4

MPEG-4 is an encapsulation format for video data, possibly combined with audio data, developed and maintained by the ISO MPEG Working Group [MPEG].

E.6 MPEG-7

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 [MPEG-7].

E.7 PWG

The printer Working Group defines attributes and capabilities applicable to printing devices [PWG]. Some of this work is incorporated into the IETF Internet Printing Protocol (IPP) [RFC2566].

Appendix F: CC/PP applications

This appendix is INFORMATIVE.

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.

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.

To make effective use of the CC/PP framework, the operating rules for the wider environment must specify:

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.

F.1 Outline of request processing in HTTP

CC/PP is envisaged to be used with HTTP in the following fashion.

(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 [CCPPEX]).

HTTP request processing
Figure F-1: HTTP request processing

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. The client receives the HTTP response and presents the content it contains.

F.2 Protocol assumptions for proxy behavior

The framework for describing proxy behaviors makes some assumptions about the protocol used to convey a CC/PP profile:


(Valid XHTML)

$Id: Overview.html,v 1.3 2018/10/09 13:29:27 denis Exp $