CC/PP Attribute Vocabularies

W3C Working Draft 21 July 2000

This version:

http://www.w3.org/TR/2000/WD-CCPP-vocab-20000721/

Latest version:

http://www.w3.org/TR/CCPP-vocab/

Editors:

Graham Klyne, GK@ACM.ORG

Copyright © 2000 W3C ^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Abstract

This document describes CC/PP (Composite Capabilities/Preference Profiles) vocabularies. It deals with vocabularies used to describe the attributes of clients, and of proxies that offer content adaptation possibilities.

It contains discussions of:

• the types of values to which CC/PP vocabularies may refer,

• a description of how to define new vocabularies,

• a small client vocabulary covering print and display capabilities,

• a vocabulary for proxies and other intermediaries to describe additional capabilities that they may provide, or constraints that they may impose,

• a survey of existing work from which new vocabularies may be derived.

It also contains an RDF schema defining the allowable combinations of vocabulary terms and values in a CC/PP profile.

Status of this document

This document is a working draft made available by the World Wide Web Consortium (W3C) for discussion only. This indicates no endorsement of its content. This is the first public working draft, and work in progress, representing the current consensus of the working group, and future updates and changes are likely.

The working group is part of the W3C Mobile Access activity. Continued status of the work is reported on the CC/PP Working Group Home Page (Member-only link).

It incorporates suggestions resulting from reviews and active participation by members of the IETF CONNEG working group and the WAP Forum UAprof drafting committee.

Please send comments and feedback to www-mobile@w3.org.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Table of contents

1. Introduction
1.1 Terminology
1.2 Outline of request processing in HTTP
2. CC/PP attribute value data types
2.1 Representing CC/PP attribute values with RDF
2.1.1 Directed labelled graph notation
2.2 Simple CC/PP attribute data
2.2.1 URI values
2.2.2 Text values
2.2.3 Integer numbers
2.2.4 Rational numbers
2.3 Complex CC/PP attribute data
2.3.1 Set of values
3. Defining vocabularies
3.1 Basic format for all vocabulary items
3.2 Use of XML namespaces
3.3 Principles for defining new attributes
3.3.1 Attribute name must be unique in profile
3.3.2 Attribute value type and interpretation
3.3.3 Interpretation not dependent on other attribute values
3.3.4 Attribute naming conventions
4. Proxy vocabulary
4.1 Capability chaining
4.2 Describing proxy behavior
4.2.1 Example: XHTML to WML transcoding
4.2.2 Example: HTML 3.2, 4.0, XHTML to WML transcoding
4.2.3 Example: JPEG image blocking
4.2.4 Example: TIFF image blocking for clients that support JPEG
4.3 CC/PP protocol assumptions
5. Client vocabulary for print and display
6. Survey of applicable vocabularies
6.1 IETF media feature registration (CONNEG)
6.2 WAP UAPROF
6.3 TIFF
6.4 WAVE
6.5 MPEG-4
6.6 MPEG-7
6.7 PWG
6.8 Salutation
6.9 JetSend
7. References
8. Acknowledgments
Appendix A: RDF Schema for CC/PP
Appendix B: Summary of standard CC/PP namespaces
Appendix X: To do

1. Introduction

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. A set of CC/PP attribute names, permissible values and associated meanings constitute a CC/PP vocabulary.

A CC/PP attribute name is a URI with optional fragment identifier. At its simplest, an attribute value is a literal text value (but applications that handle a given attribute may impose more detailed interpretation of its value). This document explains how to define attribute vocabularies for use in CC/PP profiles. It also defines some basic attributes for describing simple print or display clients, and content-handling proxy systems.

CC/PP attribute values may be constructed from a number of fundamental data types and simple structuring techniques. These are covered in the section CC/PP attribute value data types.

The general form of all attribute names, and mechanisms for introducing specific application vocabularies, are covered in the section Defining vocabularies.

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 interworking between different applications, some common vocabulary is desirable. The section Client vocabulary for print and display introduces a simple common, cross-application vocabulary, and has been partly based on some earlier IETF work. The section Proxy vocabulary describes a further vocabulary that can be used by proxies (or other intermediaries) to express capability variations corresponding to facilities and policies that they implement.

1.1 Terminology

See CC/PP Terminology and Abbreviations [10].

1.2 Outline of request processing in HTTP

CC/PP is intended to be usable in a range of protocol environments, but specifically with HTTP. It is used with HTTP in the following fashion:

Figure 1-1: HTTP request processing

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

1. The client sends an HTTP request, with an accompanying CC/PP client profile. The client profile will typically contain references to default profiles describing a range of common capabilities for the client concerned (e.g. a particular computer/operating system/browser combination, or a particular model of mobile device), and values that are variations from the default profile.

2. The HTTP request may pass through a firewall/proxy that (a) imposes constraints on the kinds of content that can be accessed, or (b) can adapt other forms of content to the capabilities of the requesting client. This proxy extends the CC/PP profile with a description of these constraints and adaptations, and sends this with the HTTP request on to the origin server. The request may pass through several such proxies.

3. The origin server receives the request and interprets the CC/PP profile. It selects and/or generates content that matches the combined proxy and client capabilities described in the profile. This is sent to the last proxy in the request chain in an HTTP response.

4. If required, the proxy applies any content adaptations, and any other functions it is designed to perform. The resulting response and content is passed back toward the requesting client.

5. The client receives the HTTP response and presents the content it contains.

2. CC/PP attribute value data types

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

2.1 Representing CC/PP attribute values with RDF

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

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

Figure 2-1: RDF statement describing a client attribute

[Client 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 feature values with basic data types; other values correspond to structured feature values.

Figure 2-2: Parts of an RDF statement

RDF subject RDF property RDF object [Client resource] --attributeName---> (Attribute-value) URI prefix:name URI or URI#fragment-ID or literal

[[[Future RDF developments may mean that all RDF objects are resources -- even literal values]]]

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

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.

All CC/PP attributes should be defined with values that can be treated as one of the simple or complex data types discussed later.

2.1.1 Directed labelled graph notation

For communication between computer systems, RDF uses a serialization in XML to represent directed labelled graphs. This XML notation is rather bulky and difficult for human discourse, so a more visual notation is used here for describing RDF graph structures:

Figure 2-3: RDF statement describing a client attribute

[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 2.3.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.

2.2 Simple CC/PP attribute data

All simple CC/PP attribute values are represented as literal text values (in XML elements or XML attributes, according to the rules for RDF literal object values).

Base CC/PP usage defined here leaves any further interpretation of the values used to the processing application. Enhancements 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, simple attribute values should be defined in terms of one of the data types described in the following sections.

Within the XML Infoset, all attribute values are sequences of Unicode characters. It is assumed that character coding issues in specific serializations of the RDF data are defined by the enclosing XML representation (or by other means if a non-XML serialization of RDF is used).

Attribute comparison is beyond the scope of this document, as are specific mechanisms for determining the simple type corresponding to a given attribute value. Possible mechanisms might include reference to schema descriptions, specific RDF properties for different comparison operators, etc.

Where given, formal syntax expressions use the notation presented in Section 6 of the XML specification [1].

2.2.1 URI values

A common requirement is to identify some resource using a URI as the value of a CC/PP attribute (e.g. a device type or an applicable DTD or schema). A URI is represented as a text string, but is subject to comparison rules set out in RFC 2396, which may require 'absolutization' of the URI [28].

2.2.2 Text values

A text value is a string that is used to describe or identify some specific feature value.

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.

2.2.2.1 Case-sensitive text

When comparing case sensitive text, every character must match exactly for equality to be declared.

Some examples:

• Browser name: "Mozilla"

• Browser version: "5.0"

2.2.2.2 Case-insensitive text

Case insensitive text values are typically used to represent arbitrary texts which may be entered or selected by hand.

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.

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

• URI scheme name: "http:"

• DNS domain name: "XYZZY.Example.com"

• Filename on some systems: "info.txt"

2.2.2.3 Tokens

Tokens are case insensitive text values using a constrained subset of US-ASCII characters, generally used to name an enumerated set of values. For the purposes of character comparison, the character ranges 'a'-'z' and 'A'-'Z' are considered equivalent. All other character values must match exactly.

The exact constraints on the characters allowed in a token value may vary from application to application; e.g. IETF media feature values that are tokens may use upper and 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:

• Charset name: "US-ASCII", "UTF-8", "I-Default"

• Language name: "en", "en-us", "fr"

2.2.3 Integer number

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.

Figure 2-4: Syntax for integer numbers

Signed-integer ::= ( '+' | '-' )? Unsigned-integer Unsigned-integer ::= Digit (Digit)*

Some examples:

• 0
• 1
• +0768
• -256

2.2.4 Rational number

A rational number is expressed as a ratio of two integer numbers. Two positive integers are separated by a '/', and optionally preceded by a '+' or '-' sign.

It is recommended that implementations generate and support numerators of a rational number (the first number, before the '/') in the range 0 to 2147483647 (2^31-1), and denominators (after the '/') in the range 1 to 2147483647.

Figure 2-5: Syntax for rational numbers

Rational-number ::= Signed-integer ( '/' Unsigned-integer )?

If the denominator is omitted, a value '1' is assumed; i.e. treat value as an Integer.

Some examples:

• 1/2 -- this is equivalent to decimal 0.5
• 768/1024
• -254/100
• +2000/65536

2.3 Complex CC/PP attribute data

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

• Set of values

2.3.1 Set of values

A set consists of zero, one or more values, all different and whose order is not significant.

Set values are useful for representing certain types of device characteristics; e.g. the range of typefaces that can be supported by a client, or the HTML versions supported by a browser.

A set is represented as an 'rdf:Bag', with each member of the set corresponding to a property of that resource named '_1', '_2', etc. This construct is described in section 3 of the RDF Model and Syntax specification [3].

Figure 2-6: RDF representation of set values in CC/PP

[<Client-resource>] +--attributeName--> [<rdf:Bag>] --rdf:_1--> (set-member-value-1) [ ] --rdf:_2--> (set-member-value-2) [ ] : [ ] --rdf:_n--> (set-member-value-n)

NOTE: The 'rdf:Bag' construct does not require that every contained value be unique. A set cannot contain duplicate values, so every property of an 'rdf:Bag' used to represent a set must have a distinct value.

A set containing just one member may be presented in a CC/PP profile as an attribute name property with a simple literal value. Properties corresponding to set valued attributes may appear more than once on a component. The resulting attribute value is the union of the members specified by all such appearances.

3. Defining vocabularies

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 CCPP relationships without necessarily understanding the CC/PP attribute names to which they refer.

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 later, in Appendix A of this document).

3.1 Basic format for all vocabulary items

All vocabulary items used by CCPP are URIs and optional fragment identifiers, used as RDF property arc identifiers. Vocabulary items used for different purposes are generally associated with different XML namespaces. Some common RDF base classes are defined so that a schema-aware RDF processor can perform improved validation of a CC/PP profile, and separate CC/PP profile elements from other statements made about any resource that appears in a CC/PP profile.

All properties used as CC/PP attributes must be instances of the class ccpp:Attribute, which itself is a subclass of rdf:Property.

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

3.2 Use of XML namespaces

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

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.

3.3 Principles for defining new attributes

3.3.1 Attribute name must be unique in a profile

[[[This point is subject to continuing debate.]]]

A CC/PP attribute should generally be defined to apply to a single specified component of a profile. In unusual cases where an attribute may be applied to more than one component, it should appear no more than once in any given profile. The meaning of any such attribute may not depend on the component to which it is applied. (For example, a hypothetical property 'version' that means a software version when applied to 'uaprof:SoftwarePlatform', and a hardware version when applied to 'uaprof:HardwarePlatform' would violate this principle. Rather, separate attribute names should be used, such as 'hardwareVersion', 'softwareVersion'.)

NOTE: the proxy vocabulary described later depends on this uniqueness of attributes 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.

Properties that may be set-valued can appear more than once in a component. The values of such properties are aggregated into a single set value. Thus two separate properties:

[<Component>] --type--> "text/html"
[<Component>] --type--> "text/xml" 

are treated as equivalent to:

[<Component>] --type--> { "text/html", "text/xml" }

3.3.2 Attribute value type and interpretation

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

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 2 "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.

3.3.3 Interpretation not dependent on other attribute values

The meaning of every attribute must be defined in isolation from other attributes: no attribute may have a meaning that changes dependent on the value of some other attribute. E.g. an attribute called, say, page-width must always be expressed using the same units: it is not acceptable for this attribute to be expressed in characters for some class of device, millimetres for another, and inches for another. (Note that it is still allowable to define an attribute that cannot be interpreted unless some other attribute is also defined; the important principle here is that adding a new attribute should not invalidate any knowledge of a client that can be deduced from attributes previously defined.)

Attributes may be defined in "layers", so that simple capabilities (e.g. ability to handle colour photographic images) can be described by a simple attribute, with additional attributes used to provide more detailed or arcane capabilities (e.g. exact colour matching capabilities).

3.3.4 Attribute naming conventions

Attributes are RDF properties. The RDF Model and Syntax document [3], Appendix C, recommends the use of "interCap" name styles for RDF property names (starting with a lower case letter, and having 2nd and subsequent words within a name started with a capital letter and no internal punctuation). We recommend such style be used for CC/PP attribute names, except where some other form is preferred for compatibility with other systems.

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

4. Proxy vocabulary

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 that play an active role in content handling. Designers of CC/PP applications that need to deal with proxy behaviours 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 client and an origin server, and modifies or filters the content passed toward the client. This in turn affects what the origin server may provide in response to a given client request, so the CC/PP information needs to be augmented with information corresponding to the proxy's behaviour.

The core proxy vocabulary names 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#>.

[[[Need to update namespace ID on final publication.]]]

4.1 Capability chaining

A proxy's role as a content modifying component between client and server is represented by chaining a description of the proxy's behaviour to the downstream client or proxy. For any given request containing a CC/PP profile, a new profile is dynamically created that refers to a CC/PP description of the proxy, and to the CC/PP capability in the request received by the 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:

Figure 4-1: Graph for client and single proxy

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

Figure 4-2: Graph for client and multiple proxies

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

Profile:

This class represents any CC/PP profile that can be delivered to an origin server .

Request-profile:

This is a subclass of CCPP-profile that is used to link a proxy profile to a downstream request or client profile. Instances of this are generally constructed on-the-fly as a request with a CC/PP profile passes through proxies on its path toward an origin server. It combines a client profile or another request profile with a proxy profile, and represents the capabilities that the proxy can accept on behalf of the client that issued the request. Because they are constructed for each request, these resources are not usefully cacheable.
NOTE: the proxy profile referenced by this item does not generally need to be constructed on-the-fly for each request.

Proxy-profile:

This class represents the capabilities and filtering behaviour of a given proxy. Instances of this class are generally constructed statically for a given configured proxy system, and may usefully be cached.

Client-profile:

This class represents the capabilities of a given client. Instances of this class are generally constructed statically for a given client system, and may usefully be cached.

proxyProfile:

This property is applied to a Request-profile instance, and indicates a Proxy-profile that is applied to the CC/PP profile associated with the corresponding request.

nextProfile:

This property is applied to a Request-profile instance, and indicates a downstream Request-profile or Client-profile with which new proxy behaviour is combined.

4.2 Describing proxy behaviour

A proxy may convert or interpret data for a client (add capabilities), or impose policy constraints (block capabilities). E.g. a proxy might provide XHTML-to-WML format conversion (which adds capabilities for downstream clients that can render WML), or may have a policy of disallowing any HTML content that contains Javascript (which blocks capabilities for clients that render HTML).

To describe such behavior, a proxy profile may contain three types of functional component:

• an indication of the clients to which the corresponding proxy behaviour is applicable, given in terms of their capabilities,

• an indication of new capabilities provided, and

• an indication of any capabilities that are blocked.

Structurally, a proxy profile mirrors the structure of a client profile, in terms of the components to which proxy behaviours apply. Component capabilities that are not affected by proxy behaviour are not included in a proxy profile.

Thus, a proxy profile description looks something like this:

Figure 4-3: Graph describing proxy behaviour

[<Proxy-profile>] +--proxyBehaviour--> [<Proxy-behaviour>] | +--applicability-->[(Attribute(s))] | +--proxyAllow----->[(Attribute(s))] | +--proxyBlock----->[(Attribute(s))] | +--proxyBehaviour--> [<Proxy-behaviour>] | +--applicability-->[(Attribute(s))] | +--proxyAllow----->[(Attribute(s))] | +--proxyBlock----->[(Attribute(s))] | +--proxyBehaviour--> [<Proxy-behaviour>] | : : (Repeat as needed for all proxy behaviours)

This framework for proxy behaviour description uses the following RDF classes and properties, defined by CC/PP.

Proxy-profile:

(See previous section.)

Proxy-behaviour:

This class represents a description of a single aspect of a proxy's behaviour; e.g. a format conversion, or a specific capability-blocking policy.

proxyBehaviour:

This property is applied to a proxy capability description, and references a Proxy-behaviour instance.

applicability:

This property is applied to a Proxy-behaviour instance, and indicates a Component value with one or more attributes indicating the requests to which the corresponding Proxy-behaviour applies. Each of the attributes thus specified must match attributes of a request for the proxy behaviour to be applicable to that request. Where an attribute is set-valued, or if an attribute name is repeated, the behaviour applies if any of the values supplied is matched by a corresponding attribute value of the request. If the applicability property is not specified, the corresponding Proxy-behaviour can apply to any request,

proxyAllow:

This property is applied to a Proxy-behaviour instance, and indicates a Component value that specifies one or more attribute values that are included by the corresponding Proxy-behaviour in the CC/PP capabilities of a request. These represent additional capabilities that are supported by the proxy on behalf of a downstream client (e.g. format conversion). If no new attributes are allowed, this property should be omitted.

proxyBlock:

This property is applied to a Proxy-behaviour instance, and indicates a Component value that specifies one or more capability attributes that are removed from the CC/PP capabilities of a request, if present. These represent capabilities that are bocked by the proxy from reaching a downstream client (e.g. content filtering). If no capabilities are bocked, this property should be omitted.

Each [(Attribute(s))] entity indicated above consists of a Component resource, whose precise type corresponds to a Component type of the applicable request profile, and whose properties are CC/PP attribute identifiers and values.

[[[It could be possible to use 'default' arcs on proxy components, just like on client components, except that they would contain proxy behaviour descriptions rather than just attribute values. The semantics of a default might be described in terms of proxy chaining: apply the defaults, then apply the local variations from them.]]]

[[[Trust issues TBD: awaiting consensus on how to practically handle web-of-trust issues in RDF. The CC/PP trust model will be subject to a separate document.]]]

4.2.1 Example: XHTML to WML transcoding

Figure 4-4a: Example 4.2.1 - graph

[<Proxy-profile>] +--proxyBehaviour--> [<Proxy-behaviour>] | ------------------ | +--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 downstream request profile includes a capability to handle WML version 1.0 or 1.1. An RDF representation of this is:

Figure 4-4b: Example 4.2.1 - RDF

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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-19991014#'> ]> <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:proxyBehaviour> <ccpp-proxy:Proxy-behaviour> <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> http://example.org/example/XHTML-1.0 </ccpp-client:schema> </ccpp:Component> </ccpp-proxy:proxyAllow> </ccpp-proxy:Proxy-behaviour> </ccpp-proxy:proxyBehaviour> </ccpp-proxy:Proxy-profile> </rdf:RDF>

4.2.2 Example: HTML 3.2, 4.0, XHTML to WML transcoding

Figure 4-5a: Example 4.2.2 - graph

[<Proxy-profile>] +--proxyBehaviour----> [<Proxy-behaviour>] | -------------------- | +--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 downstream request profile includes a capability to handle WML version 1.0 or 1.1. An RDF representation of this is:

Figure 4-5b: Example 4.2.2 - RDF

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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-19991014#'> ]> <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-2'> <ccpp-proxy:proxyBehaviour> <ccpp-proxy:Proxy-behaviour> <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> http://example.org/example/XHTML-1.0 </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-behaviour> </ccpp-proxy:proxyBehaviour> </ccpp-proxy:Proxy-profile> </rdf:RDF>

4.2.3 Example: JPEG image blocking

Figure 4-6a: Example 4.2.3 - graph

[<Proxy-profile>] +--proxyBehaviour--> [<Proxy-behaviour>] | ------------------ | +--proxyBlock--->[<Component>] +--type---------> "image/jpeg"

This example effectively removes any capability to handle JPEG image files. An RDF representation of this is:

Figure 4-6b: Example 4.2.3 - RDF

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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:proxyBehaviour> <ccpp-proxy:Proxy-behaviour> <ccpp-proxy:proxyBlock> <ccpp:Component> <ccpp-client:type> image/jpeg </ccpp-client:type> </ccpp:Component> </ccpp-proxy:proxyBlock> </ccpp-proxy:Proxy-behaviour> </ccpp-proxy:proxyBehaviour> </ccpp-proxy:Proxy-profile> </rdf:RDF>

4.2.4 Example: TIFF image blocking for clients that support JPEG

Figure 4-7a: Example 4.2.4 - graph

[<Proxy-profile>] +--proxyBehaviour----> [<Proxy-behaviour>] | -------------------- | +--applicability-->[<Component>] | +--type---------> "image/jpeg" +--proxyBlock----->[<Component>] +--type---------> "image/tiff"

This example effectively removes any capability to handle TIFF image files, which is applicable if the downstream request profile can handle JPEG. That is, always send JPEG in preference to TIFF, when possible. An RDF representation of this is:

Figure 4-7b: Example 4.2.4 - RDF

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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;' xmlns:uaprof = '&ns-uaprof;'> <ccpp-proxy:Proxy-profile rdf:about='http://www.example.com/proxy-profile-4'> <ccpp-proxy:proxyBehaviour> <ccpp-proxy:Proxy-behaviour> <ccpp-proxy:applicability> <ccpp:Component> <ccpp-client:type> image/jpeg </ccpp-client:type> </ccpp:Component> </ccpp-proxy:applicability> <ccpp-proxy:proxyBlock> <ccpp:Component> <ccpp-client:type> image/tiff </ccpp-client:type> </ccpp:Component> </ccpp-proxy:proxyBlock> </ccpp-proxy:Proxy-behaviour> </ccpp-proxy:proxyBehaviour> </ccpp-proxy:Proxy-profile> </rdf:RDF>

4.3 CC/PP protocol assumptions

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

• The CC/PP profile is conveyed in one or more parts, each containing a graph fragment, and which are combined to form a single RDF graph.

• In addition to the RDF graph, the protocol must separately name the RDF resource corresponding to the root of the current request profile.

• The current operational model is that all CC/PP profile interpretation is performed by the origin server, and none by the proxies. It may be necessary for the protocol to allow the origin server to provide information with its response that allows proxies to decide whether or not to apply any conversions that they offer; e.g. is XHTML-to-WML conversion required, or does the downstream client have native XHTML capability?

5. Client vocabulary for print and display

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.

The client attribute names defined below may be used to identify some common properties 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#>.

[[[Need to update namespace ID on final publication.]]]

deviceIdentifier:

(Value data type: URI)
A URI that serves as an identifier of the client device or user agent type.

type:

(Value data type: String, or set of Strings)
A MIME content type that can be accepted and presented by a client. Similar in principle to the HTTP 'accept:' header, but specifying a single MIME content-type, without associated content-type parameters. Multiple accepted content-types can be described by a value that is a set of content-type string values. Where needed, content-type parameters can be expressed by additional CC/PP attributes.

schema:

(Value data type: URI, or set of URIs)
A URI that identifies a schema that is recognized by the client. The schema may be an XML DTD [1], XML Schema [13], RDF Schema [4] or any other applicable document structure that can be identifed by a URI. A Schema value refines any acceptable document type indicated by the Type attribute, but its meaning must not depend on the value of Type. Typically, this will be used to indicate specific XML DTDs or schema that are recognized within text/xml or application/xml document types.

charWidth:

(Value data type: Integer)
For a text display device (type="text/*"), the width of the character display. For proportional font displays, this is the width of the display in ems (where an em is the typographical unit that is the width of an em-dash/letter 'M'?).

charHeight:

(Value data type: Integer)
For a text display device (type="text/*"), the number of lines of text that can be displayed.

charset:

(Value data type: Token (per [29]) or set of tokens)
For a text display device, a character set that can be rendered (values per MIME 'charset' parameter on content-type "text/*").

pix-x:

(Value data type: Integer)
For an image display device (type="image/*"), the number of horizontal pixels that can be displayed.

pix-y:

(Value data type: Integer)
For an image display device (type="image/*"), the number of vertical pixels that can be displayed.

color:

(Value data type: Token, per [8])
For text and image display devices, an indication of the colour capabilities (per RFC 2534 [8], possible values are "binary", "grey", "limited", "mapped" and "full").
NOTE: the color attribute provides a very coarse indication of colour capabilities, sufficient for a range of simple applications, and may be refined by additional attributes where capabilities need to be described in greater detail.

6. Survey of applicable vocabularies

This section introduces some possible sources of properties to be described by CC/PP attribute vocabularies

6.1 IETF media feature registration (CONNEG)

The IETF has defined an IANA registry for media feature tags [5] and a syntax [6] for relational-style expressions using these to describe client and server media features. A small common vocabulary has been defined [8], which has been used as a basis for the CC/PP client common vocabulary. The IETF Internet fax working group has also created additional registrations to describe the capabilities of fax machines [16].

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

• IETF tree: registered feature tags that are simple names, which are defined and assigned under the auspices of the IETF standards process.

• Global tree: registered feature tags that are simple names preceded by 'g.'. These are defined by groups other than the IETF, but are registered with IANA to ensure uniqueness of these names.

• Unregistered: feature tags that consist of 'u.' followed by a slightly restricted form of URI.

[[[Dependency here on IETF]]] There is currently a proposal to create a URN namespace for IANA registries. This would create a mechanism to allow IANA-registered feature tags to be used directly as URIs in CC/PP expressions.

Unregistered feature tags may be used in CC/PP expressions by stripping off the leading 'u.' and taking the resulting URI 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').

6.2 WAP UAPROF

UAPROF [9] is a WAP Forum specification that is designed to allow wireless mobile devices to declare their capabilities to data servers and other network components.

The design of UAPROF is 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.

• Hardware platform

• Software platform

• WAP characteristics

• Browser user agent

• Network characteristics

Although its RDF schema used is more restrictive in terms of classes and property usage that UAPROF, the design of CC/PP is broadly compatible. The goal is that valid UAPROF profiles are also valid CC/PP profiles.

6.3 TIFF

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

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 feature tags. 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.

6.4 WAVE

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

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.

6.5 MPEG-4

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

[[[More to say]]]

6.6 MPEG-7

MPEG-7 is a metadata format for information associated with image, video, audio and other data, currently in development by the ISO MPEG working group [26].

[[[More to say]]]

6.7 PWG

The printer working group defines attributes and capabilities applicable to printing devices [22]. Some of this work is incorporated into the IETF Internet Printing Protocol (IPP) [23].

6.8 Salutation

Salutation is a protocol and identification scheme for communicating devices, mainly in a LAN environment, developed and maintained by the Salutation Consortium [24]. The device capability identification mechanisms probably include many items that might be used as CC/PP attributes.

6.9 JetSend

Salutation is a protocol and identification scheme for printers, scanners and other communicating devices, mainly in a LAN environment, developed and maintained by the Hewlett Packard [25]. The device capability identification mechanisms probably include many items that might be used as CC/PP attributes.

7. References

[1]

Extensible Markup Language (XML) 1.0;
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen;
World Wide Web Consortium Recommendation: http://www.w3.org/TR/REC-xml

[2]

Namespaces in XML;
Tim Bray, Dave Hollander, Andrew Layman;
World Wide Web Consortium Recommendation: http://www.w3.org/TR/1999/REC-xml-names

[3]

Resource Description Framework (RDF) Model and Syntax Specification;
Ora Lassila, Ralph Swick;
World Wide Web Consortium Recommendation: http://www.w3.org/TR/1999/REC-rdf-syntax

[4]

Resource Description Framework (RDF) Schema Specification;
Dan Brickley, R. V. Guha;
World Wide Web Consortium Recommendation: http://www.w3.org/TR/PR-rdf-schema

[5]

RFC 2506: Media Feature Tag Registration Procedure;
K. Holtman, A. Mutz, T. Hardie;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2506.txt

[6]

RFC 2533: A Syntax for Describing Media Feature Sets;
G. Klyne;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2533.txt

[7]

A revised media feature set matching algorithm;
G. Klyne;
Internet draft, work in progress: <draft-klyne-conneg-feature-match-02.txt>

[8]

RFC 2534: Media Features for Display, Print, and Fax;
L. Masinter, D. Wing, A. Mutz, K. Holtman;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2534.txt

[9]

WAP-174: WAG UAPROF User Agent Profile Specification;
Wireless Application Group;
http://www1.wapforum.org/tech/terms.asp?doc=SPEC-UAProf-19991110.pdf

[10]

Composite Capabilities/Preference Profiles: Terminology and Abbreviations;
Mikael Nilsson;
W3C Working Draft: http://www.w3.org/TR/CCPP-ta/

[11]

Note on CC/PP combining forms and attribute value comparisons
(To be published)

[12]

Notes on Data Structuring;
C. A. R. Hoare;
in Structured Programming, Academic Press, 1972.
ISBN 0-12-2000556-2.

[13]

XML schema:

Part 0: Primer;
David C. Fallside;
W3C Working Draft: http://www.w3.org/TR/xmlschema-0/

Part 1: Structures;
Henry S. Thompson, David Beech, Murray Maloney, Noah Mendelsohn;
W3C Working Draft: http://www.w3.org/TR/xmlschema-1/

Part 2: Datatypes;
Paul V. Biron, Ashok Malhotra;
W3C Working Draft: http://www.w3.org/TR/xmlschema-2/

[14]

Composite Capabilities/Preference Profiles (CC/PP): Structure;
Franklin Reynolds, Chris Woodrow, Hidetaka Ohto;
W3C Working Draft: http://www.w3.org/TR/CCPP-struct/
CCPP Framework document

[15]

The Semantic Toolbox: Building Semantics on top of XML-RDF;
Tim Berners-Lee;
http://www.w3.org/DesignIssues/Toolbox.html

[16]

RFC 2531: Content Feature Schema for Internet Fax;
G. Klyne, L. McIntyre;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2531.txt

[17]

TIFF (Tagged Image File Format) 6.0 Specification;
Adobe Systems Inc.;
http://partners.adobe.com/asn/developer/PDFS/TN/TIFF6.pdf

[18]

RFC 2301: File Format for Internet Fax;
L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2301.txt

[19]

Multimedia Programming Interface and Data Specifications 1.0 (contains WAVE file format);
IBM Corporation and Microsoft Corporation;
<riffspec.txt>

[20]

RFC 2361: WAVE and AVI Codec Registries;
E. Fleischman;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2361.txt

[21]

MPEG-4 Overview - (V.14 - Geneva Version), ISO/IEC JTC1/SC29/WG11 N3444 Rob Koenen

Overview of the MPEG-4 Standard: http://www.cselt.it/mpeg/standards/mpeg-4/mpeg-4.htm

[22]

Printer Working Group;
http://www.pwg.org

[23]

RFC 2566: Internet Printing Protocol/1.0: Model and Semantics;
R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2566.txt

[24]

Salutation Consortium Specification;
http://www.salutation.org/

[25]

JetSend
[[[???]]]

[26]

MPEG-7 Overview (version 3.0), ISO/IEC JTC1/SC29/WG11 N3445

José M. Martínez (UPM-GTI, ES)

Overview of the MPEG-7 Standard: http://www.cselt.it/mpeg/standards/mpeg-7/mpeg-7.htm

[27]

RFC 2277: IETF Policy on Character Sets and Languages;
H. Alvestrand;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2277.txt

[28]

RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax;
T. Berners-Lee, R. Fielding, L. Masinter;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2396.txt

[29]

RFC 2278: IANA Charset Registration Procedures;
N. Freed, J. Postel;
IETF Request for Comments: ftp://ftp.isi.edu/in-notes/rfc2278.txt

[30]

Composite Capabilities/Preference Profiles: Requirements and Architecture;
Mikael Nilsson, Johan Hjelm, Hidetaka Ohto;
W3C Working Draft: http://www.w3.org/TR/CCPP-ra/

8. Acknowledgments

This document is a distillation of many discussions of the W3C CC/PP working group.

Franklin Reynolds and Hidetaka Ohto suggested many useful revisions to earlier drafts.

Appendix A: RDF Schema for CC/PP

Summary of CC/PP class hierarchy

Figure A-1: CC/PP class hierarchy

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-behaviour ccpp:Component rdfs:Literal ccpp:URI ccpp:Value {A URI value of a CC/PP attribute} ccpp:Text ccpp:Value {A text value of a CC/PP attribute} ccpp:Integer ccpp:Value {An integer value of a CC/PP attribute} ccpp:Rational ccpp:Value {A rational number CC/PP attribute value} rdf:Bag ccpp:Value {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}

Summary of CC/PP properties

Structural properties (instances of ccpp:Property)

Figure A-2: CC/PP structural properties

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:applicability Domain=ccpp:Proxy-profile, Range=ccpp:Component ccpp:proxyAllow Domain=ccpp:Proxy-profile, Range=ccpp:Component ccpp:proxyBlock Domain=ccpp:Proxy-profile, Range=ccpp:Component

Client attribute properties (instances of ccpp:Attribute)

Figure A-3: CC/PP client attribute properties

ccpp:device-identifier Domain=ccpp:Component, Range=ccpp:URI ccpp:type Domain=ccpp:Component, Range=ccpp:Text ccpp:schema Domain=ccpp:Component, Range=ccpp:URI ccpp:char-width Domain=ccpp:Component, Range=ccpp:Integer ccpp:char-height 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

RDF Schema

CC/PP core and class structure:

(Schema URI: <http://www.w3.org/2000/07/04-ccpp-schema>)

[[[Need to update namespace ID on final publication.]]]

Figure A-4: RDF schema for CC/PP classes and core properties

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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 behaviours included. For systems that do not have to deal with proxy behaviours (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 behaviour descriptions to a "downstream" request profile. 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 behaviour, 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 a "downstream" client profile or request profile. A proxy profile has an arbitrary number of ccpp:proxy-behaviour properties, each of which indicates an individual ccpp:Proxy-behaviour value. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Proxy-behaviour'> <rdfs:label>CC/PP Proxy behaviour</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;Resource'/> <rdfs:comment> A description of a single aspect of proxy behaviour. A proxy profile is made up from an arbitrary number of these individual proxy behaviours. </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 behaviour 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. Note that this is a superclass of ccpp:Value. </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. Note that this is a superclass of ccpp:Value. </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. Note that this is a superclass of ccpp:Value. </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. Note that this is a superclass of ccpp:Value. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Set'> <rdfs:label>Set value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-rdf;Bag'/> <rdfs:comment> This class is used to represent any CC/PP attribute value that is a set of simple values. From an RDF perspective, it is identical to an rdf:Bag, except that no element value may be repeated. Note that this is a superclass of ccpp:Value. </rdfs:comment> </rdfs:Class> <rdfs:Class rdf:ID='Value'> <rdfs:label>CC/PP attribute value</rdfs:label> <rdfs:subClassOf rdf:resource='&ns-ccpp;URI'/> <rdfs:subClassOf rdf:resource='&ns-ccpp;Text'/> <rdfs:subClassOf rdf:resource='&ns-ccpp;Integer'/> <rdfs:subClassOf rdf:resource='&ns-ccpp;Rational'/> <rdfs:subClassOf rdf:resource='&ns-ccpp;Set'/> <rdfs:comment> This class is used to represent any value that can be the object of a CC/PP attribute; i.e. a client feature or preference. This schema defines various literal and set values for CC/PP attributes. New applications requiring more complex values may define additional rdfs:subClass arcs. </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 deckared 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>

Vocabulary for describing proxy behaviours:

(Schema URI: <http://www.w3.org/2000/07/04-ccpp-proxy-vocabulary>)

[[[Need to update namespace ID on final publication.]]]

Figure A-5: RDF schema for proxy vocabulary

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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 behaviour description --> <!-- These properties represent some common vocabulary that is --> <!-- available for use by applications that have cause to describe --> <!-- proxy behaviours. 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 downstream 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 behaviours. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='applicability'> <rdfs:label>Proxy behaviour applicability properties</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> This is one of three properties to describe a proxy behaviour. If this property is present, the behaviour associated with the corresponding ccpp:Proxy-profile resource is applied only if the downstream request profile indicates capabilities that match all those of component that is the object of this property. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='proxy-allow'> <rdfs:label>Capabilities allowed by proxy behaviour</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> This is one of three properties to describe a proxy behaviour. If this property is present, it indicates capabilities that are allowed in addition to those indicated by the downstream request profile. </rdfs:comment> </ccpp:Attribute> <ccpp:Attribute rdf:ID='proxy-block'> <rdfs:label>Capabilities blocked by proxy behaviour</rdfs:label> <rdfs:domain rdf:resource='&ns-ccpp;Proxy-profile'/> <rdfs:range rdf:resource='&ns-ccpp;Component'/> <rdfs:comment> This is one of three properties to describe a proxy behaviour. If this property is present, it indicates capabilities that are blocked, even when they are indicated by the downstream request profile. </rdfs:comment> </ccpp:Attribute> </rdf:RDF>

Client attribute vocabulary for print and display:

(Schema URI: <http://www.w3.org/2000/07/04-ccpp-client-vocabulary>)

[[[Need to update namespace ID on final publication.]]]

Figure A-6: RDF schema for client vocabulary

<?xml version='1.0'?> <!DOCTYPE rdf:RDF [ <!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'> <!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'> <!ENTITY ns-ccpp 'http://www.w3.org/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='device-identifier'> <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='char-width'> <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='char-height'> <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>Colour 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 colour rendering capabilities: binary - indicates bi-level colour (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 colours, but not with sufficient control for displaying a colour photograph (e.g. a pen plotter, high-light printer or limited display). mapped - indicates a palettized colour display, with enough levels and control for coarse display of colour photographs. full - indicates full color display capability. </rdfs:comment> </ccpp:Attribute> </rdf:RDF>

Appendix B: Summary of standard CC/PP namespaces

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

[[[This appendix summarizes the XML namespaces introduced by this specification, and lists the common names that they define. To be completed. Update namespace names on final publication]]]

Appendix X: To do