The English version of this specification is the only normative version. Non-normative translations may also be available.
Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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:
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.
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].
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.
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.
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].
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.
This section is not normative, but provides an overview of the features of CC/PP.
A CC/PP profile is broadly constructed as a 2-level hierarchy:
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:
Figure 2-1a: CC/PP profile components
The corresponding XML might look like this:
<?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).
A CC/PP profile describes client capabilities and preferences in terms of a number of "CC/PP attributes" for each component.
The description of each component is a sub-tree whose branches are the capabilities or preferences associated with that component. Though RDF makes modeling a wide range of data structures possible, including arbitrary graphs, complex data models are usually best avoided for profile attribute values. A capability can often be described using a small number of CC/PP attributes, each having a simple, atomic value. Where more complex values are needed, these can be constructed as RDF subgraphs. One useful case for complex attribute values is to represent alternative values; e.g. a browser may support multiple versions of HTML. A hypothetical profile might look like this:
Figure 2-2a: Complete CC/PP profile example
The corresponding XML might look like this:
<?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> |
The attributes of a component can be included directly, as in the previous example, or may be specified by reference to a default profile, which may be stored separately and accessed using its specified URI.
This use of an externally defined default profile is somewhat similar to the idea of dynamic inheritance. It makes possible some important optimizations. As a separate document, it can reside at a separate location and it can be separately cached. This is particularly useful in wireless environments such as cellular networks, where the profiles may be large and the client link slow and expensive. Using default values, only a small part of the overall profile is sent over the wireless network.
Default values for a component of a CC/PP profile are indicated by a
ccpp:defaults
arc from the component concerned to a
component that describes the default values.
Figure 2-3a: CC/PP profile using defaults
The corresponding XML might look like this:
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:
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:
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.
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:
<?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 thatccpp:
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).
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.
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.
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.
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.
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:
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.
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.
<?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:
<?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 anrdf:about
whose value is a URI. This URI MUST correspond to the value of therdf: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:
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> |
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> |
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.
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:
<?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.
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.
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
.
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.)
All simple CC/PP 2.0 attributes are represented by RDF typed literal values [RDFSCHEMA].
Figure 4-6: RDF representation of a simple value in CC/PP
See the RDF Primer [RDFPRIMER] for more information on RDF usage.
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.
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.
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.)
This section explains how to make a valid claim that a product conforms to this specification. Anyone may make a claim (e.g., vendors about their own products, third parties about those products, journalists about products, etc.). Claims may be published anywhere (e.g., on the Web or in product documentation). Claimants are solely responsible for their claims. If the subject of the claim (e.g., the software) changes after the date of the claim, the claimant is responsible for updating the claim. Claimants are expected to modify or retract a claim if it may be demonstrated that the claim is not valid. Claimants are encouraged to conform to the most recent specification available.
There are three classes of products of CC/PP:
Documents 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:
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".
A producer is CC/PP conformant when any CC/PP profile document generated by the producer is a CC/PP conformant document.
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:
NOTE: A consumer implementation may be configurable to act as either a conformant consumer or a conformant validating consumer at different times.
A conformance claim is valid if it is well formed and meets the appropriate conformance criteria for the applicable product class as given above.
A conformance claim is well-formed if it includes the following information:
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).
This appendix is INFORMATIVE.
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 |
This appendix is NORMATIVE, but support by CC/PP processors is OPTIONAL.
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} |
ccpp:component Domain=ccpp:Profile, Range=ccpp:Component ccpp:defaults Domain=ccpp:Component, Range=ccpp:Component |
(Schema URI: http://www.w3.org/2006/09/20-ccpp-schema)
<?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.
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.)
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 URI: http://www.w3.org/2006/09/20-ccpp-client)
<?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> |
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).
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.
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.
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.
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.
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).
RDF class names used in CC/PP profiles preferably begin with an uppercase letter.
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.
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.
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.
RFC 2506 [RFC2506] defines three kinds of media feature tags:
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.
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.
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.
There is a registry of WAVE-supported audio codecs that might be used as CC/PP attributes [RFC2361].
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.
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]).
Figure F-1: HTTP request processing
The framework for describing proxy behaviors makes some assumptions about the protocol used to convey a CC/PP profile:
NOTE: The "current operational model" noted above does not prohibit proxies from interpreting CC/PP profiles. Rather, it means that the framework for describing proxy behaviors does not require that proxies interpret them.
$Id: Overview.html,v 1.3 2018/10/09 13:29:27 denis Exp $