Copyright © 2001 W3C ® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document describes CC/PP (Composite Capabilities/Preference Profiles) structure and vocabularies. A CC/PP profile is a description of device capabilities and user preferences that can be used to guide the adaptation of content presented to that device.
The Resource Description Framework (RDF) is used to create profiles that describe user agent and proxy capabilities and preferences. The structure of a profile is discussed. Topics include:
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. The latest status of this series of documents is maintained at the W3C.
This is a W3C Last Call Working Draft. Last call means that the working group believes that this specification is ready and therefore wishes this to be the last call for comments. If the feedback is positive, the working group plans to submit it for consideration as a W3C Proposed Recommendation. Comments can be sent until the 5th of April, 2001. The decision to issue this last call was made at the working group's meeting on November 14 , see the minutes and at the teleconference on January 11, see the minutes(Member-only link).
The working group is part of the W3CDevice Independence activity. Continued status of the work is reported on the CC/PP Working Group Home Page (Member-only link).
This document incorporates suggestions resulting from reviews and active participation by members of the IETF CONNEG working group and the WAP Forum UAprof drafting committee, and also significant restructuring decided at the CC/PP working group meeting in Karlstad during November 2000. As a result, this document is created from merge of CC/PP Structure and CC/PP Vocabularies.
Please send comments and feedback to www-mobile@w3.org, the public forum for discussion of W3C's work on Mobile Web Access.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
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.
As the number and variety of devices connected to the Internet grows, there
is a corresponding increase in the need to deliver content that is tailored
to the capabilities of different devices. Some limited techniques, such as HTTP
'accept
' headers and HTML <alt>
tags, 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, and interoperability. There is a specification that describes how to encode RDF using XML [3], and another that defines an RDF schema description language using RDF [4]. RDF was designed to describe the metadata or machine understandable properties of the Web. RDF is a natural choice for the CC/PP framework since user agent profiles are metadata intended primarily for communication between user agents and resource data providers.
A CC/PP profile contains a number of attribute names and associated values that are used by a server to determine the most appropriate form of a resource to deliver to a client. It is structured to allow a client and/or proxy to describe their 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 the Appendix F, CC/PP applications.
It is anticipated that different applications will use different vocabularies; indeed this is needed if application-specific properties are to be represented within the CC/PP framework. But for different applications to work together, some common vocabulary, or a method to convert between different vocabularies, is needed. (XML namespaces can ensure that different applications' names do not clash, but does not provide a common basis for exchanging information between different applications.) Any vocabulary that relates to the structure of a CC/PP profile must follow this specification. The appendices introduce some simple attribute vocabulary that may be used to improve cross-application exchange of capability information, partly based on some earlier IETF work.
CC/PP is designed to be broadly compatible with the earlier UAPROF specification [9] from the WAP Forum. That is, any valid UAPROF profile is intended to be a valid CC/PP profile.
CC/PP is a client profile data format, and a framework for incorporating application- and operating environment-specific features. It does not define how the profile is transferred, nor does it specify what CC/PP attributes must be generated or recognized. CC/PP is designed for use as part of a wider application framework. As such, the specification of CC/PP elements that must be supported and those which may be omitted is a matter for a specific application.
There are few protocol assumptions built into the design of CC/PP. Although it is intended to be largely protocol independent, particular consideration has been given to use of CC/PP with HTTP for retrieving web resources. Appendix F contains some further discussion of CC/PP applications.
This document describes a number of features of CC/PP. Some features form part of the essential structure of CC/PP, for which conformance is REQUIRED. Others are features whose use is RECOMMENDED or OPTIONAL. There is also discussion of how new vocabularies should be introduced, directed to CC/PP application designers rather than implementers.
The architecture section does not describe specific features, but indicates general principles that underlie the design of CC/PP. As such, it is not specifically normative but does contain information that should be understood for proper implementation of CC/PP.
The section on CC/PP structure covers three 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 RECOMMENDED -- the actual syntax for any simple CC/PP value is defined by the corresponding attribute specification; such specifications may reference the information provided here. Support for the structured CC/PP attribute formats described, where relevant, is REQUIRED.
Support is not required for any specific vocabulary, but application designers are strongly encouraged to re-use existing vocabularies where possible.
CC/PP applications are not required to support features described in the appendices, but any new attribute vocabularies defined MUST conform to the RDF schema in appendices B and C.
The remainder of this section covers terminology, conventions and notations used in this document.
Section 2 provides an overview of the CC/PP profile structure, use of XML namespaces, RDF data model and RDF Schemas.
Section 3 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 describes how attributes are used in a CC/PP profile, and presents the recommended structure of CC/PP elements used to describe specific features.
The appendices contain additional supporting material that is not essential to construct a valid CC/PP profile, but which provides additional background information useful for understanding CC/PP, its relationship with RDF, or defining attribute vocabularies for specific applications.
See CC/PP terminology and abbreviations in Appendix A of this document.
The term "CC/PP attribute" is used here to refer to a specific capability or characteristic of a client (or other system) that appears in a CC/PP profile. The term "feature" refers to a client capability or characteristic that may or may not be the basis of a CC/PP attribute. The term "attribute name" is used to indicate an RDF property name used to identify a CC/PP attribute.
In describing the construction of profiles that incorporate proxy behaviors, the terms "inbound" and "outbound" are used in the sense described in the HTTP/1.1 specification, RFC 2616 [31]. That is: "inbound" means "toward the origin server", and "outbound" means "toward the user agent".
The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," "MAY," and "MAY NOT" in this document are to be interpreted as described in RFC 2119 [25].
The underlying structure of RDF is a directed labelled graph. For communication between computer systems, RDF uses a serialization in XML to represent these graphs. This XML notation is rather bulky and difficult for human discourse, so a more visual notation is used here for describing RDF graph structures:
[Subject-resource] --propertyName--> [Object-resource] Indicates a graph edge labelled 'propertyName' from an RDF resource named 'Subject-resource' to another RDF resource names 'Object-resource'. [Subject-resource] --propertyName--> "Property value" Indicates a graph edge labelled 'propertyName' from an RDF resource named 'Subject-resource' to a literal string containing the indicated value. [Subject-resource] --propertyName--> { "Val1", "Val2", ... } This is a shorthand for a property whose value is an rdf:Bag resource containing the indicated values (see section 4.1.2.1). [<Subject-type>] --propertyName--> [<Object-type>] Names in angle brackets are used to indicate an RDF resource of the indicated type (i.e. having the indicated rdf:Type property value), without indicating a specific name for the resource. This is useful for showing the RDF classes that may be linked by a property. [Subject-resource] --propertyName--> [Object-resource] | ------------------------------- | +--property1--> (val1) +--property2--> (val2) : (etc.) Property arcs can be chained, and multiple arcs drawn from a subject resource. |
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!-- Any RDF graph is an RDF element --> <RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns="http://www.example.com/schema#"> <!-- [Subject-resource] -propertyName-> [Object-resource] --> <rdf:Description rdf:about="Subject-resource"> <propertyName> <rdf:Description rdf:about="Object-resource" /> </propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> [Object-resource] - (Alternative format) --> <rdf:Description rdf:about="Subject-resource"> <propertyName rdf:resource="Object-resource" /> </rdf:Description> <!-- [Subject-resource] -propertyName-> "property value" --> <rdf:Description rdf:about="Subject-resource"> <propertyName>Property value</propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... } --> <rdf:Description rdf:about="Subject-resource"> <propertyName> <rdf:Description> <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag" /> <rdf:li>Val1</rdf:li> <rdf:li>Val1</rdf:li> <!-- ...etc... --> </rdf:Description> </propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> { "Val1", "Val2", ... } - (Alternative format) --> <rdf:Description rdf:about="Subject-resource"> <propertyName> <rdf:Bag> <rdf:li>Val1</rdf:li> <rdf:li>Val1</rdf:li> <!-- ...etc... --> </rdf:Bag> </propertyName> </rdf:Description> <!-- [<Subject-type>] -propertyName-> [<Object-type>] --> <rdf:Description> <rdf:type rdf:resource="Subject-type" /> <propertyName> <rdf:Description> <rdf:type rdf:resource="Object-type" /> </rdf:Description> </propertyName> </rdf:Description> <!-- [Subject-resource] -propertyName-> [Object-resource] - | - +-property1-> (val1) - +-property2-> (val2) - : --> <rdf:Description rdf:about="Subject-resource"> <propertyName> <rdf:Description rdf:about="Object-resource" > <property1>val1</property1> <property2>val2</property2> <!-- ...etc... --> </rdf:Description> </propertyName> </rdf:Description> </RDF> |
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:
[Profile] | +--ccpp:component-->[TerminalHardware] |
The corresponding XML might look like this:
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="Profile"> <ccpp:component> <rdf:Description rdf:about="TerminalHardware"> <!-- TerminalHardware properties here --> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="TerminalSoftware"> <!-- TerminalSoftware properties here --> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description about="TerminalBrowser"> <!-- TerminalBrowser properties here --> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF> |
A CC/PP profile describes client capabilities and preferences in terms of a number of "CC/PP attributes" for each component.
The description of each component is a sub-tree whose branches are the capabilities or preferences associated with that component. Though RDF makes modeling a wide range of data structures possible, including arbitrary graphs, complex data models are usually best avoided for profile attribute values. A capability can often be described using a small number of CC/PP attributes, each having a simple, atomic value. Where more complex values are needed, these can be constructed as RDF subgraphs. One useful 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:
[MyProfile] | +--ccpp:component-->[TerminalHardware] | | | +--rdf:type---> [HardwarePlatform] | +--display----> "320x200" | |
The corresponding XML might look like this:
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="MyProfile"> <ccpp:component> <rdf:Description rdf:about="TerminalHardware"> <rdf:type rdf:resource="HardwarePlatform" /> <display>320x200</display> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="TerminalSoftware"> <rdf:type rdf:resource="SoftwarePlatform" /> <name>EPOC</name> <version>2.0</version> <vendor>Symbian</vendor> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="TerminalBrowser"> <rdf:type rdf:resource="BrowserUA" /> <name>Mozilla</name> <version>5.0</version> <vendor>Symbian</vendor> <htmlVersionsSupported> <rdf:Bag> <rdf:li>3.0</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </htmlVersionsSupported> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF> |
The attributes of a component can be included directly, as in the previous example, or may be specified by reference to a default profile, which may be stored separately and accessed using its specified URI.
This use of an externally defined default properties 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.
[MyProfile] | +--ccpp:component--> [TerminalHardware] | | | +--rdf:type-------> [HardwarePlatform] | +--ccpp:defaults--> [HWDefault] | |
The corresponding XML might look like this:
Device profile referencing defaults:<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="MyProfile"> <ccpp:component> <rdf:Description rdf:about="TerminalHardware"> <rdf:type rdf:resource="HardwarePlatform" /> <ccpp:defaults rdf:resource="HWDefault" /> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="TerminalSoftware"> <rdf:type rdf:resource="SoftwarePlatform" /> <ccpp:defaults rdf:resource="SWDefault" /> </rdf:Description> </ccpp:component> <ccpp:component> <rdf:Description rdf:about="TerminalBrowser"> <rdf:type rdf:resource="BrowserUA" /> <ccpp:defaults rdf:resource="UADefault" /> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF>Defaults for HardwarePlatform: <?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="HWDefault"> <rdf:type rdf:resource="HardwarePlatform" /> <display>320x200</display> </rdf:Description> </rdf:RDF>Defaults for SoftwarePlatform: <?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="SWDefault"> <rdf:type rdf:resource="SoftwarePlatform" /> <name>EPOC</name> <version>2.0</version> <vendor>Symbian</vendor> </rdf:Description> </rdf:RDF>Defaults for BrowserUA: <?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="UADefault"> <rdf:type rdf:resource="BrowserUA" /> <name>Mozilla</name> <version>5.0</version> <vendor>Symbian</vendor> <htmlVersionsSupported> <rdf:Bag> <rdf:li>3.0</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </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:
[MyProfile] | +--ccpp:component--> [TerminalHardware] | +--rdf:type-------> [HardwarePlatform] +--ccpp:defaults--> [HWDefault] +--memory---------> "32Mb" [HWDefault] | +--rdf:type---> [HardwarePlatform] +--display----> "320x200" +--memory-----> "16Mb" |
In this example, the default component indicates 16Mb of memory, but this value
is overridden by the memory
property applied directly to the profile
component. Thus, in this profile, the memory
attribute has a value
of 32Mb.
The corresponding XML might look like this:
Device profile referencing defaults:<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="MyProfile"> <ccpp:component> <rdf:Description rdf:about="TerminalHardware"> <rdf:type rdf:resource="HardwarePlatform" /> <ccpp:defaults rdf:resource="HWDefault" /> <memory>32Mb</memory> </rdf:Description> </ccpp:component> </rdf:Description> </rdf:RDF>Defaults for HardwarePlatform: <?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"> <rdf:Description rdf:about="HWDefault"> <rdf:type rdf:resource="HardwarePlatform" /> <display>320x200</display> <memory>16Mb</memory> </rdf:Description> </rdf:RDF> |
A resource indicated by a default property may appear in a separate document,
in which case an absolute URI reference should be specified for the default
resource. In such cases, the URI part of the default resource identifier (i.e.
not including the fragment identifier part) is used to retrieve an RDF document
containing the default resource description. Thus, if the default resource is
named http://example.com/DeviceProfile#HardwarePlatform
, the URI
http://example.com/DeviceProfile
is used to retrieve an RDF document,
and a resource within that document having the local identifier #HardwarePlatform
is taken as the default resource. (Such a resource might be defined within the
target document using "about='http://example.com/DeviceProfile#HardwarePlatform'
"
or "ID='HardwarePlatform'
". See also section 3.1.5.)
NOTE: individual applications may allow relative URIs to be used. Those that do should specify exactly how the corresponding RDF document is located.
It may be that an intervening network element, such as a transcoding proxy, has additional capabilities it wishes to advertise on the behalf of its clients. For instance, a transcoding proxy may be able to convert HTML to WML. The means to provision such a proxy (meaning to provide or not provide the service for some client) is beyond the scope of this work. But assuming such a proxy based capability is provided, CC/PP provides means for a proxy to describe its own capabilities as part of the CC/PP profile communicated to an origin server.
In the example below, the proxy profile showing its capabilities combined with a client profile by a request profile link element. This is not a particularly representative example, but it does illustrate how a proxy profile can contain different kinds of component information:
Client Profile:[ClientProfile] | +--ccpp:component-->[TerminalHardware] | | | +--rdf:type---> [HardwarePlatform] | +--display----> "320x200" |Proxy Profile: [ProxyProfile] | +--proxyBehavior--> [ ] | | | +--proxyAllow--> [ProxyHardware] | | | +--rdf:type--> [HardwarePlatform] | +--cpu-------> "Pentium III" | +--proxyBehavior--> [ ] | | | +--proxyAllow--> [ProxyOS] | | | +--rdf:type--> [SoftwarePlatform] | +--name------> "Linux" | +--vendor----> "Linux.com" | +--version---> "5.0" | +--proxyBehavior--> [ ] | +--proxyAllow--> [Proxy] | +--rdf:type--> [ProxyComponent] +--name------> "" +--vendor----> "Interleaf" +--version---> "1.0" +--html4.0towml1.1--> "Yes"Request Profile: [RequestProfile] | +--nextProfile---> [ClientProfile] +--proxyProfile--> [ProxyProfile] |
Examples of proxy behavior descriptions in XML can be found in section 3.2.
There may be multiple intervening network hosts, each of which, needs to be able to indicate some capability. In general, the order in which these network hosts are encountered is important. For example, consider an installation with a firewall that filters some types of unsafe content and a transcoding proxy that converts the unsafe content to a safe form. If the proxy is behind the firewall then the origin server cannot send the unsafe form for the transcoding proxy to convert, because the firewall will block it first. But it is a different story if the proxy is in front of the firewall.
To indicate sequence of proxies on a path, multiple request profiles (each referencing a proxy profile) can be chained together. Proxies that are closer to the origin server appear earlier in the chain, with the client profile being last in the chain:
[<Request-profile-n>] +--proxyProfile--> [<Proxy-profile-n>] +--nextProfile---> [<Request-profile-(n-1)>] | ----------------- | v [<Request-profile-(n-1)>] : : v [<Request-profile-2>] +--proxyProfile--> [<Proxy-profile-2>] +--nextProfile---> [<Request-profile-1>] | ----------------- | v [<Request-profile-1>] +--proxyProfile--> [<Proxy-profile-1>] +--nextProfile---> [<Client-profile>] +--component--> [...] |
An XML version of this is presented in section 3.2.1.
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 [8], and serves as an example of how CC/PP attribute vocabularies may be defined. Another such example is the WAP Forum UAPROF specification [9].
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 [2] define a notation for associating convenient name forms with arbitrary URIs. The RDF graph syntax does not specifically employ namespaces, but XML serializations of an RDF graph do. We also use namespace prefixes when presenting RDF in the graph notation described above.
There is a reasonable expectation that a designated (globally unique) namespace will have associated semantics, including schema-related semantics. Thus, there is a convention that a namespace URI is associated with a corresponding schema document, though the specific mechanism for determining such an association is not formally defined. (The RDF schema specification does say that the namespace identifier is also used as a schema identifier.)
The CC/PP framework uses the XML namespace mechanism to create identifying URIs for RDF core elements, CC/PP structural elements and CC/PP attribute vocabularies. Consider the following namespace declaration example:
<?xml version="1.0"?> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> |
The first two namespace declarations are for RDF usage. The third declaration
names the CC/PP core structural vocabulary, which includes "component
",
"defaults
" and other properties that are intrinsic to the CC/PP
framework. The fourth namespace declaration names a component properties vocabulary.
The use of multiple component property vocabularies is allowed and encouraged. Different user communities and application domains (WAP Forum, ETSI, MExE, IETF CONNEG, etc.) may define their own property vocabularies. This is an important mechanism for providing support for the needs of those communities.
The following namespaces are introduced by the CC/PP framework:
http://www.w3.org/2000/07/04-ccpp#
RDF class declarations for CC/PP, and core structural properties.http://www.w3.org/2000/07/04-ccpp-proxy#
Vocabulary for describing proxy behaviors in a CC/PP profile.http://www.w3.org/2000/07/04-ccpp-client#
Vocabulary for describing simple client capabilities, with particular relevance to print and display clients.
RDF is defined in the RDF Model and Syntax specification [3].
The foundation of RDF is a directed labelled graph used to represent entities, concepts and relationships between them. This RDF model draws on principles of knowledge representation developed over the past decades in the artificial intelligence community, notably conceptual graphs [32]. A broader background to knowledge representation issues can be found in Sowa's book Knowledge Representation [33]. RDF extends the traditional approach to knowledge representation by placing it in the open context of the World Wide Web, in which anybody may make any statement about anything.
The nodes of an RDF graph are resources, which may stand for entities or concepts. Commonly, these nodes stand for web resources, but RDF itself does not impose any such constraint on the nature of a resource.
The arcs of an RDF graph are properties. Commonly, these are used to denote attributes of a resource, but may also be used to indicate any relationship between any pair of resources.
The fundamental construct of RDF is a statement, which corresponds to a labelled directed arc between two nodes of the graph. A statement thus consists of three components: an originating resource known as the subject of the statement, a target resource (or literal) known as the object, and a property known as the predicate:
RDF subject RDF predicate RDF object [Resource] ----attributeName----> (Attribute-value) URI prefix:name URI or URI#fragment-ID or literal |
Thus, the basic RDF data model consists of three object types:
http://www.w3.org/Overview.html
,
for example. A resource may be a part of a Web page; e.g. a specific HTML
or XML element within the document source. A resource may also be a whole
collection of pages; e.g. an entire Web site. A resource may also be an object
that is not directly accessible via the Web; e.g. a printed book. Resources
are always named by URIs plus optional anchor ids (see RFC2396 [28]).
Anything can have a URI; the extensibility of URIs allows the introduction
of identifiers for any entity imaginable.An RDF graph is expressed in XML using syntax described in the RDF Model and Syntax specification [3].
An RDF subject resource and a number of associated properties is contained
in an <rdf:Description>
element, with an rdf:ID=
or rdf:about=
attribute identifying the subject resource.
Each property is expressed as a child element of the <rdf:Description>
element whose content is either another resource description or the literal
value of the property, or as an empty property element with an rdf:resource=
attribute identifying a resource that is described elsewhere:
<Description rdf:about="http://example.com/MyProfile"> <ccpp:component> <Description rdf:about="http://example.com/Schema#TerminalHardware"> <rdf:type rdf:resource="http://example.com/Schema#HardwarePlatform" /> <prf:cpu>PPC</prf:cpu> <prf:display>320x200</prf:display> </Description> </ccpp:component> </Description> |
The RDF graph described by this is:
[http://example.com/MyProfile] | +--ccpp:component-->[http://example.com/Schema#TerminalHardware] | ----------------- | +--rdf:type-------> [http://example.com/Schema#HardwarePlatform] +--prf:cpu--------> "PPC" +--prf:display----> "320x200" |
A complete RDF serialization consists of an <rdf:RDF>
element containing a sequence of such descriptions (and appropriate namespace
declarations):
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://example.com/schema#"> <Description about="http://example.com/MyProfile"> <ccpp:component> <Description about="http://example.com/schema#TerminalHardware"> <type resource="http://example.com/Schema#HardwarePlatform" /> <prf:cpu>PPC</prf:cpu> <prf:display>320x200</prf:display> </Description> </ccpp:component> <!-- ...etc... --> </Description> </RDF> |
This is the so-called "basic RDF serialization syntax. RDF also defines some abbreviated forms that can be used, as appropriate, to make the XML data more compact, and in some cases easier to read:
rdf:type
property value as element name for
a resource description,<rdf:Description>
element attributes to
represent literal property values, andrdf:resource=
attribute of a property element
to indicate a resource value, together with additional attributes to indicate
literal properties of the indicated resource.The first of these abbreviation forms is often used to construct RDF serialization that looks similar to commonly used XML forms. using this, the inner description of the above example would become:
<prf:HardwarePlatform rdf:about="http://example.com/schema#TerminalHardware"> <prf:cpu>PPC</prf:cpu> <prf:display>320x200</prf:display> </prf:HardwarePlatform> |
Note that when used as an attribute value, a resource identifier URI must be written out in full. When used as an element name or attribute name, a namespace prefix form must be used to conform to XML syntax. (This is one of the oddities of the XML serialization syntax of RDF.)
RDF properties may be thought of as attributes of resources and in this sense used to represent traditional attribute-value pairs. RDF properties also represent relationships between resources. As such, the RDF data model can therefore resemble an entity-relationship diagram. The RDF data model, however, provides no mechanisms for declaring these properties, nor does it provide any mechanisms for defining the relationships between these properties and other resources. That is the role of RDF Schema.
RDF schema introduces the key concept of a "class". This provides the basis for categorizing RDF resources and properties, and provides the fundamental mechanism for constructing RDF ontologies. (Ontology applies the idea of a data type to a wide range of entities and concepts; it thus provides a basis for organizing and categorizing resources about which statements are made.)
An RDF schema can declare constraints associated with classes and properties.
In particular, the concepts of domain and range are used to make statements
about the kinds of resource that can be related by a given property. Although
the RDF data model does not allow for explicit properties (such as an rdf:type
property) to be ascribed to Literals (atomic string values), we nevertheless
consider these entities to be members of classes (e.g. the string "John Smith"
is considered to be a member of the class rdfs:Literal
).
Specifc constraint types that may be defined by an RDF schema are rdfs:domain
and rdfs:range
. For example, consider that a resource of
type 'Book
' may have a property 'author
' whose value
is a 'Person
':
rdfs:domain
expresses that a property can be applied
only to instances of a designated class; e.g. that the subject of any 'author
'
property must be an instance of class 'Book
'.rdfs:range
expresses that an indicated property must
have a value that is an instance of a designated class; e.g. that the object
of any 'author
' property must be an instance of class 'Person
'.RDF schemas can express constraints that relate vocabulary items from multiple independently developed schemas. Since URI references are used to identify classes and properties, it is possible to create new properties whose domain or range is constrained to be a class defined in another namespace.
The RDF Schema uses the constraint properties to constrain how its own properties can be used. These constraints are shown below in figure 7. Nodes with bold outlines are instances of rdfs:Class.
Figure 2-12: Constraints in RDF schema
Please refer to the RDF Schema [4] for a more complete description of RDF Constraints.
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 a number of components. Each component
is represented by a resource of type ccpp
:Component
(or some subclass thereof), and related to the client profile resource by a
ccpp:component
property.
A CC/PP profile based on three components (TerminalHardware
, TerminalSoftware
and TerminalBrowser
), would look like this:
[Profile] | +--ccpp:component-->[TerminalHardware] |
A ccpp:Component
resource MAY have an rdf:type
property (or equivalent RDF structure) indicating what kind of client component
it describes. The example in figures 3-4 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.
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 [3]. The RDF data model represents CC/PP attributes as named properties linking a subject resource to an associated object resource or literal value.
To describe client capabilities and preferences, the client being described is a resource whose features are described by labelled 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.
[Client component resource] --attributeName--> (Attribute-value) |
Graph labels are XML name values (per XML specification [1], section 2.3), which may include a namespace prefix (i.e. a qualified name, per XML namespaces [2], section 3). When combined with the corresponding namespace or default namespace declaration, each label can be mapped to a URI. Thus, CC/PP attributes are URIs, with XML namespace syntax used to avoid some of the RDF expressions becoming too cumbersome.
RDF object values are resources (identified by a URI without fragment identifier), resource fragments (identified by a URI with fragment identifier) or literal values (text strings). The literal values correspond to CC/PP attribute values with basic data types; other values correspond to structured CC/PP attribute values.
RDF subject RDF property RDF object [Client resource] --attributeName---> (Attribute-value) URI prefix:name URI or URI#fragment-ID or literal |
Basic data types are discussed in the section Simple CC/PP attribute data. 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. Further discussion of CC/PP attribute matching operations is deferred to a separate document [10].
Structured data types are supported through the use of specific RDF properties that join simple data values into composites. Specific CC/PP semantics for RDF properties used in this way are discussed in the section Complex CC/PP attribute data.
Each component of a client profile may indicate a separate resource that in turn indicates a subordinate collection of default attribute values. This collection of default values can be a separate RDF document that is named via a URI, or can appear in the same document as the client profile (though, in practice, there is probably little value in defaults in the same document). If an attribute in the collection of defaults is also present in the main part of the client profile, the non-default value takes precedence. The intent is that a hardware vendor or system supplier may provide default values that are common to a number of systems in a place easily accessible to an origin server, and then use the client profile to specify variations from the common profile. The owner of the product or system operator may be able to add or change options, such as additional memory, that add new capabilities or change the values of some original capabilities.
Default values are referenced by the property ccpp
:defaults
.
This name conforms to the name format recommendations of the RDF model and syntax
specification [3], appendix C.1. However, for compatibility
with earlier versions of CC/PP used with UAPROF, CC/PP processors SHOULD recognize
the property name ccpp:Defaults
(i.e. with capital "D")
as equivalent.
Defaults can be encoded inline or as separate documents referred to via URI. 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:
[MyProfile] | +--ccpp:component--> [TerminalHardware] | | | +--rdf:type-------> [HardwarePlatform] | +--ccpp:defaults--> [HWDefault] | +--display--------> "640x400" | |
And here is the corresponding XML serialization, with the default resource descriptions coded inline in the client profile description:
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> <Description about="http://example.com/MyProfile"> <ccpp:component> <Description about="http://example.com/TerminalHardware"> <type resource="http://example.com/Schema#HardwarePlatform"/> <ccpp:defaults> <Description about="http://example.com/HWDefault"> <type resource="http://example.com/Schema#HardwarePlatform"/> <prf:cpu>PPC</prf:cpu> <prf:display>320x200</prf:display> </Description> </ccpp:defaults> <prf:display>640x400</prf:display> </Description> </ccpp:component> <ccpp:component> <Description about="http://example.com/TerminalSoftware"> <type resource="http://example.com/Schema#SoftwarePlatform" /> <ccpp:defaults> <Description about="http://example.com/SWDefault"> <type resource="http://example.com/Schema#SoftwarePlatform"/> <prf:name>EPOC</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>2.0</prf:version> </Description> </ccpp:defaults> </Description> </ccpp:component> <ccpp:component> <Description about="http://example.com/Browser"> <type resource="http://example.com/Schema#BrowserUA" /> <ccpp:defaults> <Description about="http://example.com/UADefault"> <type resource="http://example.com/Schema#BrowserUA"/> <prf:name>Mozilla</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>5.0</prf:version> <prf:htmlVersionsSupported> <Bag> <li>3.0</li> <li>4.0</li> </Bag> </prf:htmlVersionsSupported> </Description> </ccpp:defaults> <prf:htmlVersionsSupported> <Bag> <li>3.0</li> <li>4.0</li> <li>XHTML</li> </Bag> </prf:htmlVersionsSupported> </Description> </ccpp:component> </Description> </RDF> |
Inline defaults are logically equivalent to defaults contained in externally referenced document, and external documents would be normal way of referencing default values. The following is the external the XML serialization of the same profile using externally referenced defaults:
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> <Description about="http://example.com/MyProfile"> <ccpp:component> <Description about="http://example.com/TerminalHardware"> <type resource="http://example.com/Schema#HardwarePlatform"/> <ccpp:defaults rdf:resource="http://example.com/HWDefault"/> <prf:display>640x400</prf:display> </Description> </ccpp:component> <ccpp:component> <Description about="http://example.com/TerminalSoftware"> <type resource="http://example.com/Schema#SoftwarePlatform" /> <ccpp:defaults rdf:resource="http://example.com/SWDefault"/> </Description> </ccpp:component> <ccpp:component> <Description about="http://example.com/Browser"> <type resource="http://example.com/Schema#BrowserUA" /> <ccpp:defaults rdf:resource="http://example.com/UADefault"/> <prf:htmlVersionsSupported> <Bag> <li>3.0</li> <li>4.0</li> <li>XHTML</li> </Bag> </prf:htmlVersionsSupported> </Description> </ccpp:component> </Description> </RDF> |
Each external defaults resource is a separate RDF document referenced by a URI.
NOTE: A default document uses a
<Description>
element as its root node. The<Description>
is named using anabout=
attribute whose value is a URI. This URI MUST correspond to the value in therdf:resource=
attribute in the<Defaults>
element in the referencing document. In the examples of default documents below, the URLs of the external default values documents are used. However the default resource URI does not have to be the document URL, as long as the URI is uniquely identified, the same URI is used in both the source document and the external default values document, and there is some way for the processing software to locate and retrieve the document containing the default resource.
Examples of default documents referenced by the previous example are as follows:
Document: http://example.com/HWDefault<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> <Description about="http://example.com/HWDefault"> <type resource="http://example.com/Schema#HardwarePlatform"/> <prf:cpu>PPC</prf:cpu> <prf:display>320x200</prf:display> </Description> </RDF> |
Document: http://example.com/SWDefault<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> <Description about="http://example.com/SWDefault"> <type resource="http://example.com/Schema#SoftwarePlatform"/> <prf:name>EPOC</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>2.0</prf:version> </Description> </RDF> |
Document: http://example.com/UADefault<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> <Description about="http://example.com/UADefault"> <type resource="http://example.com/Schema#BrowserUA"/> <prf:name>Mozilla</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>5.0</prf:version> <prf:htmlVersionsSupported> <Bag> <li>3.0</li> <li>4.0</li> </Bag> </prf:htmlVersionsSupported> </Description> </RDF> |
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).
The graph in figure 2-2a above can be described in RDF in a relatively straightforward
fashion. In this example we use the namespace "http://www.wapforum.org/UAPROF/ccppschema-20000405#
"
to describe all the non-CC/PP properties:
<?xml version="1.0"?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#" xmlns:prf="http://www.wapforum.org/UAPROF/ccppschema-20000405#"> <Description about="http://example.com/MyProfile"> <ccpp:component> <Description about="http://example.com/TerminalHardware"> <type resource="http://example.com/Schema#HardwarePlatform" /> <prf:cpu>PPC</prf:cpu> <prf:display>320x200</prf:display> </Description> </ccpp:component> <ccpp:component> <Description about="http://example.com/TerminalSoftware"> <type resource="http://example.com/Schema#SoftwarePlatform" /> <prf:name>EPOC</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>2.0</prf:version> </Description> </ccpp:component> <ccpp:component> <Description about="http://example.com/Browser"> <type resource="http://example.com/Schema#BrowserUA" /> <prf:name>Mozilla</prf:name> <prf:vendor>Symbian</prf:vendor> <prf:version>5.0</prf:version> <prf:htmlVersionsSupported> <Bag> <li>3.0</li> <li>4.0</li> </Bag> </prf:htmlVersionsSupported> </Description> </ccpp:component> </Description> </RDF> |
All RDF resources that relate to the overall structure of CC/PP are defined in a specific namespace, and have certain associated schema properties that allow them to be distinguished from attribute vocabulary or other RDF statements.
In this specification, names of RDF resource nodes are given by "about" so they can be addressed from outside (i.e. from other RDF documents) when the containing document does not have an assigned URI. (This is used for describing proxy profile and capability chaining, when the profile information is contained in a transitory unnamed protocol element.)
RDF Model and Syntax specification [3] defines two ways to name RDF resources, namely "ID" and "about". RDF resources named by "about" are fully identified, whereas those named by "ID" can not be referenced from outside the containing document, unless some additional information is available that allows the full (absolute) base URI to be determined. The RDF specification is not currently clear about how a base URI should be determined [34].
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 MUST be identified as such, by means of the rdf
:type
property whose value matches the name of the component type in the schema.
The proxy vocabulary defined here is not a mandatory part of the CC/PP specification, but is defined here for use by CC/PP aware applications that may need to deal with proxies or other intermediaries that play an active role in content handling. Designers of CC/PP applications that need to deal with mediating behaviors are strongly encouraged to use this vocabulary rather than define new structures.
For the purposes of this specification, a proxy is a component that sits on the network path between a content consumer and a content provider, and modifies or filters the content passed toward the consumer. This in turn affects what the provider may send to a given client, so the consumer's CC/PP information needs to be augmented with information corresponding to the proxy's behavior. (For typical web access, the origin server is the provider, and the client is the consumer.)
This approach to describing proxy behaviors does not force a proxy to analyze and rewrite a client profile. Rather, the applicability, proxyAllow and proxyBlock properties allow a proxy describe its behavior in a way that takes account of a client's capabilities. As a result, the structure is very easy for a proxy to create, though it does place some additional responsibility on an origin server to analyze and combine the various parts appropriately.
The proxy description elements below are described using XML namespace local parts, which are further qualified by the XML namespace identifier <http://www.w3.org/2000/07/04-ccpp-proxy#>.
A simple case is a client request that passes through a single proxy; the resulting request profile received by the origin server looks like this:
[<Request-profile>] +--proxyProfile--> [<Proxy-profile>] +--nextProfile---> [<Client-profile>] |
A more complex case occurs when a request passes through several proxies, each of which adds its own description to the overall profile:
[<Request-profile-n>] +--proxyProfile--> [<Proxy-profile-n>] +--nextProfile---> [<Request-profile-(n-1)>] | ---------------- | v [<Request-profile-(n-1)>] : : v [<Request-profile-2>] +--proxyProfile--> [<Proxy-profile-2>] +--nextProfile---> [<Request-profile-1>] | ---------------- | v [<Request-profile-1>] +--proxyProfile--> [<Proxy-profile-1>] +--nextProfile---> [<Client-profile>] +--component--> [...] : (etc.) |
This framework for proxy chaining uses the following RDF classes and properties, defined by CC/PP.
The corresponding XML might look like this:
Proxy profile n:<rdf:Description rdf:about="Proxy_n"> <rdf:type rdf:resource="Proxy-profile" /> <!-- Proxy_n profile properties here --> : </rdf:Description>Request profile n: <rdf:Description rdf:about="Request_n"> <rdf:type rdf:resource="Request-profile" /> <ccpp:proxyProfile rdf:resource="Proxy_n" /> <ccpp:nextProfile rdf:resource="Request_(n-1)" /> </rdf:Description> :Request profile 2: <rdf:Description rdf:about="Request_2"> <rdf:type rdf:resource="Request-profile" /> <ccpp:proxyProfile rdf:resource="Proxy_2" /> <ccpp:nextProfile rdf:resource="Request_1" /> </rdf:Description>Request profile 1: <rdf:Description rdf:about="Request_1"> <rdf:type rdf:resource="Request-profile" /> <ccpp:proxyProfile rdf:resource="Proxy_1" /> <ccpp:nextProfile rdf:resource="Client" /> </rdf:Description>Client profile: <rdf:Description rdf:about="Client"> <rdf:type rdf:resource="ClientProfile" /> <ccpp:component> : </ccpp:component> </rdf:Description> |
To describe such behavior, a proxy profile may contain three types of functional component:
None of these are required in every case, but a proxy behavior description
without either proxyAllow
or proxyBlock
would be rather
pointless. Therefore, in practice, at least one of these should be present.
Thus, a proxy profile description looks something like this:
[<Proxy-profile>] +--proxyBehavior--> [<Proxy-behavior>] | +--applicability--> (Attribute(s)...) | +--proxyAllow-----> (Attribute(s)...) | +--proxyBlock-----> (Attribute(s)...) | +--proxyBehavior--> [<Proxy-behavior>] | +--applicability--> (Attribute(s)...) | +--proxyAllow-----> (Attribute(s)...) | +--proxyBlock-----> (Attribute(s)...) | +--proxyBehavior--> [<Proxy-behavior>] | : : (Repeat as needed for all proxy behaviors) |
This framework for proxy behavior description uses the following RDF classes and properties, defined by CC/PP.
[<Proxy-profile>] +--proxyBehavior--> [<Proxy-behavior>] | ------------------ | +--applicability-->[<Component>] | | | ---------------- | | | +--uaprof:WmlVersion--> { "1.0", "1.1" } | +--proxyAllow----->[<Component>] | ---------------- | +--type----> { "text/xml", "application/xml"} +--schema--> { "http://example.org/example/XHTML-1.0" } |
This example effectively adds a capability to a profile to handle XHTML, which is applicable if the request profile received from the outbound system includes a capability to handle WML version 1.0 or 1.1. An RDF representation of this is:
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> <!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'> <!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'> <!ENTITY ns-uaprof 'http://www.wapforum.org/UAPROF/ccppschema-20000405#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;' xmlns:ccpp-proxy = '&ns-ccpp-proxy;' xmlns:ccpp-client = '&ns-ccpp-client;' xmlns:uaprof = '&ns-uaprof;'> <ccpp-proxy:Proxy-profile rdf:about='http://www.example.com/proxy-profile-1'> <ccpp-proxy:proxyBehavior> <ccpp-proxy:Proxy-behavior> <ccpp-proxy:applicability> <ccpp:Component> <uaprof:WmlVersion> <rdf:Bag> <rdf:li>1.0</rdf:li> <rdf:li>1.1</rdf:li> </rdf:Bag> </uaprof:WmlVersion> </ccpp:Component> </ccpp-proxy:applicability> <ccpp-proxy:proxyAllow> <ccpp:Component> <ccpp-client:type> <rdf:Bag> <rdf:li>text/xml</rdf:li> <rdf:li>application/xml</rdf:li> </rdf:Bag> </ccpp-client:type> <ccpp-client:schema> <rdf:Bag> <rdf:li>http://example.org/example/XHTML-1.0</rdf:li> </rdf:Bag> </ccpp-client:schema> </ccpp:Component> </ccpp-proxy:proxyAllow> </ccpp-proxy:Proxy-behavior> </ccpp-proxy:proxyBehavior> </ccpp-proxy:Proxy-profile> </rdf:RDF> |
[<Proxy-profile>] +--proxyBehavior----> [<Proxy-behavior>] | -------------------- | +--applicability-->[<Component>] | | | ---------------- | | | +--uaprof:WmlVersion--> { "1.0", "1.1" } | +--proxyAllow----->[<Component>] | ---------------- | +--type---------> { "text/xml", "application/xml"} +--type---------> { "text/html", "application/html"} +--schema-------> { "http://example.org/example/XHTML-1.0" } +--uaprof:HTMLVersion--> { "3.2", "4.0" } |
This example effectively adds a capability to a profile to handle HTML 3.2 or 4.0, or XHTML, which is applicable if the request profile received from the outbound system includes a capability to handle WML version 1.0 or 1.1. An RDF representation of this is:
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> <!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'> <!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'> <!ENTITY ns-uaprof 'http://www.wapforum.org/UAPROF/ccppschema-20000405#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;' xmlns:ccpp-proxy = '&ns-ccpp-proxy;' xmlns:ccpp-client = '&ns-ccpp-client;' xmlns:uaprof = '&ns-uaprof;'> <ccpp-proxy:Proxy-profile rdf:about='http://www.example.com/proxy-profile-2'> <ccpp-proxy:proxyBehavior> <ccpp-proxy:Proxy-behavior> <ccpp-proxy:applicability> <ccpp:Component> <uaprof:WmlVersion> <rdf:Bag> <rdf:li>1.0</rdf:li> <rdf:li>1.1</rdf:li> </rdf:Bag> </uaprof:WmlVersion> </ccpp:Component> </ccpp-proxy:applicability> <ccpp-proxy:proxyAllow> <ccpp:Component> <ccpp-client:type> <rdf:Bag> <rdf:li>text/xml</rdf:li> <rdf:li>application/xml</rdf:li> </rdf:Bag> </ccpp-client:type> <ccpp-client:type> <rdf:Bag> <rdf:li>text/html</rdf:li> <rdf:li>application/html</rdf:li> </rdf:Bag> </ccpp-client:type> <ccpp-client:schema> <rdf:Bag> <rdf:li>http://example.org/example/XHTML-1.0</rdf:li> </rdf:Bag> </ccpp-client:schema> <uaprof:HTMLVersion> <rdf:Bag> <rdf:li>3.2</rdf:li> <rdf:li>4.0</rdf:li> </rdf:Bag> </uaprof:HTMLVersion> </ccpp:Component> </ccpp-proxy:proxyAllow> </ccpp-proxy:Proxy-behavior> </ccpp-proxy:proxyBehavior> </ccpp-proxy:Proxy-profile> </rdf:RDF> |
[<Proxy-profile>] +--proxyBehavior--> [<Proxy-behavior>] | ------------------ | +--proxyBlock--->[<Component>] +--type---------> { "image/jpeg" } |
This example effectively removes any capability to handle JPEG image files. An RDF representation of this is:
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> <!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'> <!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;' xmlns:ccpp-proxy = '&ns-ccpp-proxy;' xmlns:ccpp-client = '&ns-ccpp-client;'> <ccpp-proxy:Proxy-profile rdf:about='http://www.example.com/proxy-profile-3'> <ccpp-proxy:proxyBehavior> <ccpp-proxy:Proxy-behavior> <ccpp-proxy:proxyBlock> <ccpp:Component> <ccpp-client:type> <rdf:Bag> <rdf:li>image/jpeg</rdf:li> </rdf:Bag> </ccpp-client:type> </ccpp:Component> </ccpp-proxy:proxyBlock> </ccpp-proxy:Proxy-behavior> </ccpp-proxy:proxyBehavior> </ccpp-proxy:Proxy-profile> </rdf:RDF> |
[<Proxy-profile>] +--proxyBehavior----> [<Proxy-behavior>] | -------------------- | +--applicability-->[<Component>] | +--type---------> { "image/jpeg" } +--proxyBlock----->[<Component>] +--type---------> { "image/tiff" } |
This example effectively removes any capability to handle TIFF image files, and is applicable if the outbound request profile indicates capability to handle JPEG. That is, always send JPEG in preference to TIFF, when possible. An RDF representation of this is:
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> <!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'> <!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-ccpp-client#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;' xmlns:ccpp-proxy = '&ns-ccpp-proxy;' xmlns:ccpp-client = '&ns-ccpp-client;'> <ccpp-proxy:Proxy-profile rdf:about='http://www.example.com/proxy-profile-4'> <ccpp-proxy:proxyBehavior> <ccpp-proxy:Proxy-behavior> <ccpp-proxy:applicability> <ccpp:Component> <ccpp-client:type> <rdf:Bag> <rdf:li>image/jpeg</rdf:li> </rdf:Bag> </ccpp-client:type> </ccpp:Component> </ccpp-proxy:applicability> <ccpp-proxy:proxyBlock> <ccpp:Component> <ccpp-client:type> <rdf:Bag> <rdf:li>image/tiff</rdf:li> </rdf:Bag> </ccpp-client:type> </ccpp:Component> </ccpp-proxy:proxyBlock> </ccpp-proxy:Proxy-behavior> </ccpp-proxy:proxyBehavior> </ccpp-proxy:Proxy-profile> </rdf:RDF> |
This section describes the basic data types and data structuring options that are available for the values associated with a CCPP attribute.
All CC/PP attributes should be defined with values that can be treated as one of the simple or complex data types discussed later. Support for the described formats for attribute values is RECOMMENDED; this specification does not prohibit the use of other valid RDF forms, but provides no guidance for their interpretation. (See also section 1.1 and Appendix F.)
Base CC/PP usage defined here leaves any further interpretation of the values used to the processing application. Future versions of CC/PP may introduce additional structures that provide for standardized matching of client profiles with other resource metadata. To allow such developments, and to ease interworking with IETF media feature descriptions, it is recommended that any simple attribute values should be defined in terms of one of the data types described below.
All attribute values are ultimately sequences of UCS (Unicode) characters. It is assumed that character coding issues in specific serializations of the RDF data are defined by the enclosing XML representation.
NOTE: Attribute comparison is beyond the scope of this document, as are specific mechanisms for determining the simple type corresponding to a given attribute value. Applications are presumed to know how to deal with any CC/PP attribute that they handle.
Where given, formal syntax expressions use the notation presented in Section 6 of the XML specification [1].
In general, such values may be compared for equality or inequality. Depending on the application and context, such comparison may be compared in different ways, as indicated below. In the absence of specific knowledge to the contrary, case sensitive text should be assumed.
Some examples:
Such values may be compared for equality, where upper and lower case characters are considered equivalent. The application and surrounding context should indicate a language or character coding context to be used for the purposes of determining equivalent upper- and lower- case characters.
NOTE: It is not safe to assume that 'a'-'z' and 'A'-'Z' are equivalent in all language contexts: text should be considered to be case sensitive unless the language context is known. Many protocol elements, such as domain names and URIs, are not intended to be in any specific language, in these contexts,the protocol should make it clear what character coding and matching rules apply [27].
Some examples:
The exact constraints on the characters allowed in a token value may vary from application to application; e.g. IETF media feature values that are tokens may use upper and lower case letters, digits and hyphens [6]; IETF charset names [29] are defined to allow any US-ASCII character other than control characters (0-31), space (32) double quote (34) and specified special characters: "(", ")", "<", ">", "@", ",", ";", ":", "/", "[", "]", "?", ".", "=" and "*".
Some examples:
Integer numbers may be positive, zero or negative. They are represented by
a string containing a sequence of decimal digits, optionally preceded by a '+'
or '-' sign. Leading zeros are permitted and are ignored. The number
value is always interpreted as decimal (radix 10). It is recommended that implementations
generate and support integer values in the range -2147483647 to +2147483647,
or -(2^31-1) to (2^31-1); i.e. integers whose absolute value can be expressed
as a 31-bit unsigned binary number.
Signed-integer ::= ( '+' | '-' )? Unsigned-integer Unsigned-integer ::= Digit (Digit)* |
Some examples:
NOTE: the choice of recommended number range support was based on support from Java and other programming languages widely used for the Web.
It is recommended that implementations generate and support numerators of a rational number (the first number, before the '/') in the range 0 to 2147483647 (2^31-1), and denominators (after the '/') in the range 1 to 2147483647.
Rational-number ::= Signed-integer ( '/' Unsigned-integer )? |
If the denominator is omitted, a value '1' is assumed; i.e. treat value as an Integer.
Some examples:
Set values are useful for representing certain types of device characteristics; e.g. the range of typefaces that can be supported by a client, or the HTML versions supported by a browser.
A set is represented as an 'rdf:Bag', with each member of the set corresponding to a property of that resource named '_1', '_2', etc. This construct is described in section 3 of the RDF Model and Syntax specification [3].
[<Client-resource>] +--attributeName--> [<rdf:Bag>] +--rdf:_1--> (set-member-value-1) +--rdf:_2--> (set-member-value-2) : +--rdf:_n--> (set-member-value-n) |
NOTE: The 'rdf:Bag' construct does not require that every contained value be unique. A set cannot contain duplicate values, so every property of an 'rdf:Bag' used to represent a set must have a distinct value.
There is a clear distinction drawn between an attribute that has a single value, and an attribute whose value is a set with zero, one or more elements:
[<Client-resource>] +--attributeName--> [<rdf:Bag>] --rdf:_1--> (set-member-value) |
[<Client-resource>] +--attributeName--> (attribute-value) |
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/2000/07/04-ccpp-client#
and the core vocabulary name:
type
are combined to yield the attribute name URI:
http://www.w3.org/2000/07/04-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, or publication of a new vocabulary definition containing detailed descriptions of the various CC/PP attribute names.
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 RDF schema with which all CC/PP profiles must conform, and Appendix C contains an example of a vocabulary definition schema. Appendix D contains recommendations for creating a new vocabulary.
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 document is a distillation of many discussions of the W3C CC/PP working group. The following were working group members for some or all of the period of preparation of this specification, and its predecessors:
Useful revisions and clarifications were suggested by Yuichi Koike, Stuart Williams, Sean Palmer and Toni Penttinen.
CC/PP | Composite Capabilities/Preferences Profile |
---|---|
CC/PPex | CC/PP Exchange Protocol |
CONNEG | Content Negotiation Working Group in the IETF |
ER | Entity-Relationship |
HTML | Hyper Text Markup Language |
HTTP | Hyper Text Transfer Protocol |
HTTPex | HTTP Extension Framework |
IANA | Internet Assigned Numbers Authority |
IETF | Internet Engineering Task Force |
IOTP | Internet Open Trading Protocol |
LDAP | Lightweight Directory Access Protocol |
OTA | Over The Air, i.e. in the radio network |
P3P | Project for Platform for Privacy Preferences |
RDF | Resource Description Framework |
RFC | Request For Comments |
TBD | To Be Determined |
TCP/IP | Transmission Control Protocol/Internet Protocol |
UAProf | 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 Hyper-Text Markup Language |
XSL | Extensible Style Language |
XML | Extensible Markup Language |
rdfs:Resource ccpp:Resource {A thing whose properties are asserted} ccpp:Profile {Profile deliverable to origin server} ccpp:Request-profile ccpp:Client-profile ccpp:Proxy-profile ccpp:Proxy-behavior ccpp:Component rdfs:Literal ccpp:URI {A URI value of a CC/PP attribute} ccpp:Text {A text value of a CC/PP attribute} ccpp:Integer {An integer value of a CC/PP attribute} ccpp:Rational {A rational number CC/PP attribute value} rdf:Bag {A set value of a CC/PP attribute} rdf:Property ccpp:Property {A property applied to a CCPP:Resource} ccpp:Attribute {A property denoting a CC/PP attribute} |
ccpp:component Domain=ccpp:Client-profile, Range=ccpp:Component ccpp:defaults Domain=ccpp:Component, Range=ccpp:Component ccpp:nextProfile Domain=ccpp:Request-profile, Range=ccpp:Profile ccpp:proxyProfile Domain=ccpp:Request-profile, Range=ccpp:Proxy-profile ccpp:proxyBehavior Domain=ccpp:Proxy-profile, Range=ccpp:Proxy-behavior ccpp:applicability Domain=ccpp:Proxy-behavior, Range=ccpp:Component ccpp:proxyAllow Domain=ccpp:Proxy-behavior, Range=ccpp:Component ccpp:proxyBlock Domain=ccpp:Proxy-behavior, Range=ccpp:Component |
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;'> <!-- CC/PP class definitions --> <rdfs:Class rdf:ID='Resource'> <rdfs:label>CC/PP Resource</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/> <rdfs:comment> This is a common base class for all resources whose properties may be asserted in a CC/PP profile. (Note that the values of CC/PP attributes are not necessarily instances of this class.) </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Profile'> <rdfs:label>CC/PP Profile</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Resource'/> <rdfs:comment> This class is any complete profile that can be delivered to an origin server or other system that generates content for a client. May be a Request-profile or a Client-profile. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Client-profile'> <rdfs:label>CC/PP Client profile</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Profile'/> <rdfs:comment> A subclass of ccpp:Profile that represents a client profile, without any intervening proxy behaviors included. For systems that do not have to deal with proxy behaviors (e.g. transcoding, etc.) this is the only profile class that needs to be instantiated. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Request-profile'> <rdfs:label>CC/PP Request profile</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Profile'/> <rdfs:comment> A subclass of ccpp:Profile that represents a profile created from a client profile and one or more Proxy-profiles. This is used to add proxy behavior descriptions to a request profile received from an outbound proxy or client system. See properties ccpp:proxy-profile' and 'ccpp:next-profile'. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Proxy-profile'> <rdfs:label>CC/PP Proxy profile</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Resource'/> <rdfs:comment> A complete description of a proxy's behavior, such as a transcoding proxy that affects the range of content that may be generated to satisfy a request. A ccpp:Request-profile is used to attach a proxy profile to an outbound client profile or request profile. A proxy profile has an arbitrary number of ccpp:proxy-behavior properties, each of which indicates an individual ccpp:Proxy-behavior value. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Proxy-behavior'> <rdfs:label>CC/PP Proxy behavior</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Resource'/> <rdfs:comment> A description of a single aspect of proxy behavior. A proxy profile is made up from an arbitrary number of these individual proxy behaviors. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Component'> <rdfs:label>CC/PP profile component</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Resource'/> <rdfs:comment> 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. uaprof:HardwarePlatform, uaprof:SoftwarePlatform). This class is also used for collecting CC/PP attributes that form part of a proxy behavior description. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='URI'> <rdfs:label>URI value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment> This class is used to represent any CC/PP attribute value that is a URI identifying an arbitrary resource. When this type is used, the value of the CC/PP attribute is the URI rather than the resource identified by the URI. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Text'> <rdfs:label>Text value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment> This class is used to represent any CC/PP attribute value that is arbitrary text. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Integer'> <rdfs:label>Integer value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment> This class is used to represent any CC/PP attribute value that is an integer number. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Rational'> <rdfs:label>Rational value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/> <rdfs:comment> This class is used to represent any CC/PP attribute value that is a rational number. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Property'> <rdfs:label>CC/PP Property</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdf;Property'/> <rdfs:comment> All property arcs that constitute parts of a CC/PP profile are defined as subclasses of ccpp:Property. This allows that in a schema-validating environment with language missing, the CC/PP elements of an RDF graph rooted in some given resource can be isolated from other attributes of that resource. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Attribute'> <rdfs:label>CC/PP Attribute</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/> <rdfs:comment> All property arcs that represent client capabilities or preferences in a CC/PP profile are declared as subclasses of ccpp:Attribute. This allows that structural combining elements of a profile can be distinguished from client features in a schema-validating environment. </rdfs:comment> </rdfs:Class> <!-- CC/PP structural property definitions --> <!-- Basic client profile description --> <rdfs:Property rdf:ID='component'> <rdfs:label>CC/PP component property</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Client-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> Indicates a component of a top-level client profile. </rdfs:comment> </rdfs:Property> <rdfs:Property rdf:ID='defaults'> <rdfs:label>CC/PP default properties</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> 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> </rdfs:Property> <rdfs:Property rdf:ID='Defaults'> <rdfs:label>CC/PP default properties</rdfs:label> <rdfs:subPropertyOf rdf:resource='&ns-ccpp;defaults'/> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> Same as 'defaults'. Defined as sub-property for backwards compatibility with UAPROF </rdfs:comment> </rdfs:Property> </rdf:RDF> |
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> <!ENTITY ns-ccpp-proxy 'http://www.w3.org/2000/07/04-ccpp-proxy#'> ]> <rdf:RDF xmlns:rdf = '&ns-rdf;' xmlns:rdfs = '&ns-rdfs;' xmlns:ccpp = '&ns-ccpp;'> xmlns:ccpp-proxy = '&ns-ccpp-proxy;'> <!-- CC/PP structural property definitions --> <!-- Proxy behavior description --> <!-- These properties represent some common vocabulary that is --> <!-- available for use by applications that have cause to describe --> <!-- proxy behaviors. They serve as an example of how new --> <!-- structural vocabulary can be defined for use in a CC/PP --> <!-- profile. --> <ccpp:Attribute rdf:ID='next-profile'> <rdfs:label>Next profile in chain</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Request-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Profile'/> <rdfs:comment> When a request passes through a proxy that affects the content that may satisfy a request (such as a transcoding proxy), this property links from a new request profile resource to the outbound client or request profile. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='proxy-profile'> <rdfs:label>Next profile in chain</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Request-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Proxy-profile'/> <rdfs:comment> When a request passes through a proxy that affects the content that may satisfy a request (such as a transcoding proxy), this property links from a new request profile resource to the profile that describes the proxy behaviors. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='proxyBehavior'> <rdfs:label>Proxy behavior property</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Proxy-behavior'/> <rdfs:comment> A proxy profile has a number of proxyBehavior properties, each of which describes some aspect of the proxy's capabilities. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='applicability'> <rdfs:label>Proxy behavior applicability properties</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-behavior'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> This is one of three properties to describe a proxy behavior. If this property is present, the behavior associated with the corresponding ccpp:Proxy-behavior resource is applied only if the outbound request profile indicates capabilities that match all those of the Component that is the object of this property. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='proxyAllow'> <rdfs:label>Capabilities allowed by proxy behavior</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-behavior'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> This is one of three properties to describe a proxy behavior. If this property is present, it indicates capabilities that are allowed in addition to those indicated by the outbound request profile. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='proxyBlock'> <rdfs:label>Capabilities blocked by proxy behavior</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-behavior'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> This is one of three properties to describe a proxy behavior. If this property is present, it indicates capabilities that are blocked, even when they are indicated by the outbound request profile. </rdfs:comment> </ccpp:Attribute> </rdf:RDF> |
The vocabulary defined here is not a mandatory part of the core CC/PP format specification, but is defined here for use by CC/PP aware applications that may need to describe certain common features. 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 [8].
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/2000/07/04-ccpp-client#>.
ccpp:deviceIdentifier Domain=ccpp:Component, Range=ccpp:URI ccpp:type Domain=ccpp:Component, Range=ccpp:Text ccpp:schema Domain=ccpp:Component, Range=ccpp:URI ccpp:charWidth Domain=ccpp:Component, Range=ccpp:Integer ccpp:charHeight Domain=ccpp:Component, Range=ccpp:Integer ccpp:charset Domain=ccpp:Component, Range=ccpp:Text ccpp:pix-x Domain=ccpp:Component, Range=ccpp:Integer ccpp:pix-y Domain=ccpp:Component, Range=ccpp:Integer ccpp:color Domain=ccpp:Component, Range=ccpp:Text |
<?xml version='1.0'?> <!-- Checked by SiRPAC 1.16, 18-Jan-2001 --> <!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/2000/07/04-ccpp#'> <!ENTITY ns-ccpp-client 'http://www.w3.org/2000/07/04-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:ID='deviceIdentifier'> <rdfs:label>Client device identifier</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;URI'/> <rdfs:comment> A URI that identifies the type of client device or user agent. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='type'> <rdfs:label>MIME content type</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Set'/> <rdfs:comment> 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:ID='schema'> <rdfs:label>Schema identifier</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;URI'/> <rdfs:comment> 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:ID='charWidth'> <rdfs:label>Character display width</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Integer'/> <rdfs:comment> 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:ID='charHeight'> <rdfs:label>Character display height</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Integer'/> <rdfs:comment> For character displays, the number of rows of characters that can be displayed. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='charset'> <rdfs:label>Character set encoding</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Set'/> <rdfs:comment> For character displays, the MIME 'charset' values that can be displayed. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='pix-x'> <rdfs:label>Pixel display width</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Integer'/> <rdfs:comment> For raster displays, the width of the display in pixels. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='pix-y'> <rdfs:label>Pixel display height</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Integer'/> <rdfs:comment> For raster displays, the height of the display in pixels. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='color'> <rdfs:label>Color display capabilities</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Component'/> <rdfs:range rdf:resource='&ns-ccpp;Text'/> <rdfs:comment> 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> |
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 B 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.
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 resource. 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 should 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.
NOTE: the proxy vocabulary described later depends on this uniqueness of attribute names in a profile.NOTE: if there a given property is required to appear on more than one component, several new properties might be defined to be rdfs:subPropertyOf a common property. This allows a common definition to be re-used without violating this uniqueness requirement.
Where possible, for ease of processing and compatibility with other frameworks, attribute values should be based on one of the data types described in section 4 "CC/PP attribute value data types" of this document.
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.
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 upper case 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.
This section introduces some possible sources of properties to be described by CC/PP attribute vocabularies
RFC 2506 [5] 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 string.
Future work may define 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').
The design of UAPROF is already based on RDF. As such, its vocabulary elements use the same basic format that is used for CC/PP.
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.
Although its RDF schema used is more restrictive in terms of classes and property usage that UAPROF, the design of CC/PP is backwards compatible. The goal is that valid UAPROF profiles are also valid CC/PP profiles, but not all CC/PP profiles are necessarily valid UAPROF 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 [16]; 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 [20].
IETF work in progress for voice messaging (VPIM/IVM) could create IETF media feature registry tags that are usable by CC/PP profiles through the same mechanisms described in section 6.1 above.
CC/PP is a format framework designed to be used in the context of a wider application or operational environment. 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, particular 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:
+------+ (5) (4) +-------+ +------+ |Client| <==response== | Proxy | <==response== |Origin| <====> (Resource) | UA | ===request==> | | ===request==> |server| (3) ( data ) +------+ (1) | +-------+ (2) | +------+ | | v v (Client ) <--- (Client profile) <----- (Request profile) (defaults) + local values | v (Proxy ) <--- (Proxy profile) (defaults) + local values |
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.
20010223 | Published as First Working Draft. |
20001218 | Document created from merge of architecture, structure and vocabulary documents. |
20001219 | Move some vocabulary and proxy material from section to into sections 3 and 4. Various small edits. |
20010109 | Various editorial fixes. Merge appendices dealing with print and display vocabulary. Remove some vocabulary source references. Add XML examples to many of the RDF graph examples. Reorganize material in sections 2 and 3, moving some technical detail to section 3. Move discussion of CC/PP applications to a new appendix. Assign figure numbers. |
20010112 | More group review editorial comments. Fixed some schema errors. Moved client schema summary to appendix C. Updated UAPROF reference and namespace URI. Added working group members to acknowledgements.. |
20010116 | More group review editorial comments. Added citation of RFC2119. Changed some instances of rdf:Bag to {...} notation in graph descriptions. Use ccpp:defaults consistently in examples; add note about allowing ccpp:Defaults for compatibility with UAPROF. Section 2.1.3: added some additional text about references to external defaults. Added points for allowed URIs and resolution mechanisms in appendix F. Figure 3-12 notation change. Section 4.1: attempt to further clarify what is required behavior. Section 4.3, add paragraph about support of RDF schema. Appendix D: add text recommending use of RDF schema to define vocabularies. Section 3.1.1, add text about use of rdf:type properties for ccpp:Component resources. Appendix B: remove references to cpp:Set and ccpp:Value. |
20010118 | Validate RDF examples with SiRPAC (W3C online facility) and correct errors detected. Fix up some internal links. |
20010129 | Add hyperlinked ToC (courtesy of "htmltoc" by Earl Hood) |
Various | Update summary of namespaces; update namespace names |
(Various examples, 3.1.5) | Review issue of RDF resource naming using 'rdf:about=' vs 'ID='. Currently, CC/PP defines use of 'rdf:about=' in the absence of a clear mechanism for naming CC/PP documents that do not have a defined URI (e.g. CC/PP as a transient protocol element). |
Supply text or delete editorial annotations | |