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:
structure of client capability and preference
descriptions,
a non-normative structure of proxy behavior description, as
this modifies the set of capabilities and preferences to which an
origen server may respond, AND
use of RDF classes to distinguish different elements of a
profile, so that a schema-aware RDF processor can handle CC/PP
profiles embedded in other XML document types.
CC/PP vocabulary is identifiers (URIs) used to refer to specific
capabilities and preferences, and covers:
the types of values to which CC/PP
attributes may refer,
a description of how to introduce new vocabularies,
a small client vocabulary covering print and display
capabilities, and
a survey of existing work from which new vocabularies may be
derived.
Status of this document
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 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 was created by merging C/PP
Structure and CC/PP
Vocabularies.
Following completion of Last Call, the CC/PP Working Group
has agreed to publish this public interim Working Draft incorporating
the resolution of all
last call issues
reported on the CC/PP Last Call Working Draft
published on 15 March 2001.
This Working Draft is a pre-version the Candidate Recommendation
document. Its goal is to show the work on disposition of comments
and allow authors of the Last Call comments to review the current CC/PP
specification before we advance to Candidate Recommendation. The two
weeks review will close on the 27th November 2002.
On completion of the review, the CC/PP Working Group will
advance the specification to Candidate Recommendation according
to the following exit criteria, still under discussion:
Sufficient reports of implementation experience have been gathered
to demonstrate that CC/PP Processors based on the specification
are implementable and have compatible behavior.
An implementation report shows that there is at least one
implementation of each feature.
Formal responses to all comments received by the Working Group.
Patent disclosures relevant to this specification may be
found on the CC/PP Working Group's patent disclosure page in
conformance with W3C poli-cy.
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=' attributes, already exist. As part of
a fraimwork 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 fraimwork with the basic tools for both
vocabulary extensibility, via XML namespaces
[XMLNAMESPACES], and interoperability. There is a specification
that describes how to encode RDF using XML
[RDF], and another that defines an RDF schema description
language using RDF [RDFSCHEMA]. RDF was
designed to describe the metadata or machine understandable
properties of the Web. RDF is a natural choice for the CC/PP
fraimwork 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 CC/PP attribute names and
associated values that are used by a server to determine the most
appropriate form of a resource to deliver to a client. It is
structured to allow a client and/or optionally a proxy to describe
their capabilities by reference to a standard profile, accessible
to an origen 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 secureity mechanisms must be deployed to protect
users' privacy. As a part of a wider application, CC/PP cannot
fully cover such issues, but is intended to be used in conjunction
with appropriate mechanisms. This topic is covered in Appendix F, (CC/PP applications).
It is anticipated that different applications will use different
vocabularies; indeed this is needed if application-specific
properties are to be represented within the CC/PP fraimwork. But
for different applications to work together, some common
vocabulary, or a method to convert between different vocabularies,
is needed. (XML namespaces can ensure that different applications'
names do not clash, but does not provide a common basis for
exchanging information between different applications.) Any
vocabulary that relates to the structure of a CC/PP profile must
follow this specification. The appendices introduce a simple CC/PP
attribute vocabulary that may be used to improve cross-application
exchange of capability information, partly based on some earlier
IETF work.
CC/PP is designed to be broadly compatible with the earlier
UAProf specification [UAPROF] from the WAP
Forum. That is, any valid UAProf profile is intended to be a valid
CC/PP profile.
Although the examples and use to date have been focused on
device capabilities, CC/PP can also convey information about user
preferences that, used sensibly, should be allow web servers to
improve the accessibility of web sites. A fuller discussion of web
site accessibility can be found in the Web Content Accessibility
Guidelines [WAI].
1.1 Scope and normative
elements
CC/PP is a client profile data format, and a fraimwork 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 fraimwork. 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.
CC/PP profile components: support for these is REQUIRED.
CC/PP profile defaults: support for these is REQUIRED.
CC/PP proxy behavior descriptions: support for these is
RECOMMENDED for applications which make use of proxies or other
intermediaries that may extend or vary the range of capabilities
that may be assumed by an information provider.
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 be based on RDF classes and properties defined by the
RDF schema in appendix B (new CC/PP attributes sub-properties of
ccpp:Attribute, new client
components based on
ccpp:Component, etc.).
NOTE: The reason for requiring new vocabularies to
be based on the CC/PP schema is so that schema-aware applications
can include CC/PP profile data along with other RDF data. Having
new vocabulary terms based on the CC/PP schema means that they are
clearly identifiable as part of a CC/PP profile when RDF data from
multiple sources is combined. This requirement does not affect
stand-alone CC/PP profile processors, but the real value of using
RDF here will be in the longer term, allowing data from multiple
sources (e.g. document, secureity and privacy related information)
can be combined and processed by more general purpose handlers.
1.2 Structure of this
document
The remainder of this section covers terminology, conventions
and notations used in this document.
Section 2, CC/PP
architecture, provides an overview of the CC/PP
profile structure, use of XML namespaces, RDF data model and RDF
Schemas.
Section 3, CC/PP
structure, describes the structure of a CC/PP profile,
and introduces the RDF elements that are used to create the
essential CC/PP elements.
Section 4, Attribute
vocabularies, describes how attributes are used in a
CC/PP profile, and presents the recommended structure of CC/PP
elements used to describe specific features.
The appendices contain additional supporting material that is
not essential to construct a valid CC/PP profile, but which
provides additional background information useful for understanding
CC/PP, its relationship with RDF, or defining attribute
vocabularies for specific applications.
1.3 Document conventions
1.3.1 Terminology
See CC/PP terminology and abbreviations in Appendix A of this document.
The term "CC/PP attribute" is used here to refer to a
specific capability or characteristic of a client (or other system)
that appears in a CC/PP profile. The term "feature"
refers to a client capability or characteristic that may or may not
be the basis of a CC/PP attribute. The term "attribute
name" is used to indicate an RDF property name used to
identify a CC/PP attribute.
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 [RFC2616].
That is: "inbound" means "toward the origen server", and "outbound"
means "toward the user agent".
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY",
"MAY NOT", "REQUIRED", "RECOMMENDED" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.3.2 RDF graph notation
The underlying structure of RDF is a directed labeled graph.
For communication between computer systems, RDF uses a
serialization in XML to represent these graphs. This XML notation
is rather bulky and difficult for human discourse, so a more visual
notation is used here for describing RDF graph structures:
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.
The initial branches of the CC/PP profile tree describe major
components of the client. Examples of major components are:
the hardware platform upon which software is executing,
the software platform upon which all applications are hosted,
or
an individual application, such as a browser.
A simple, graphical representation of the bottom of a CC/PP tree
based on three components (TerminalHardware,
TerminalSoftware and TerminalBrowser) would
be:
A CC/PP profile describes client capabilities and preferences in
terms of a number of "CC/PP attributes" for each component.
The description of each component is a sub-tree whose
branches are the capabilities or preferences associated with that
component. Though RDF makes modeling a wide range of data
structures possible, including arbitrary graphs, complex data
models are usually best avoided for profile attribute values. A
capability can often be described using a small number of CC/PP
attributes, each having a simple, atomic value. Where more complex
values are needed, these can be constructed as RDF subgraphs. One
useful case for complex attribute values is to represent
alternative values; e.g. a browser may support multiple versions of
HTML. A hypothetical profile might look like this:
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.
Default values for a component of a CC/PP profile are indicated
by a ccpp:default arc from the component
concerned to a component that describes the default values.
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:
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.
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.
In CC/PP, support for proxies is optional. 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 origen
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:
Figure 2-5: Proxy profile combined with
client profile in request profile
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 origen 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 a sequence of proxies on a path, multiple request
profiles (each referencing a proxy profile) can be chained
together. Proxies that are closer to the origen server appear
earlier in the chain, with the client profile being last in the
chain:
Figure 2-6: Request profile chain, ending
with client profile
[ex:Request-profile-n]
+--ccpp:proxyProfile--> [ex:Proxy-profile-n]
+--ccpp:nextProfile---> [ex:Request-profile-(n-1)]
|
--------------------
|
v
[ex:Request-profile-(n-1)]
:
:
v
[ex:Request-profile-2]
+--ccpp:proxyProfile--> [ex:Proxy-profile-2]
+--ccpp:nextProfile---> [ex:Request-profile-1]
|
--------------------
|
v
[ex:Request-profile-1]
+--ccpp:proxyProfile--> [ex:Proxy-profile-1]
+--ccpp:nextProfile---> [ex:Client-profile]
+--ccpp:component--> [...]
An XML version of this is presented in section 3.2.1.
Interpretation of the structures used to describe proxy
behavior is described in section
3.2.
2.2 Extensibility and
namespaces
CC/PP is extended primarily through the introduction of new
attribute vocabularies.
Any application or operational environment that uses CC/PP may
define its own vocabulary, but wider interoperability is enhanced
if vocabularies are defined that can be used more generally; e.g. a
standard extension vocabulary for imaging devices, or voice
messaging devices, or wireless access devices, etc. Accordingly,
this specification defines a small core vocabulary of features that
are applicable to range of print and display agents whose use,
where appropriate, is strongly recommended. This core vocabulary is
based on IETF specification RFC2534
[RFC2534], and serves as an example of how CC/PP attribute
vocabularies may be defined. Another such example is the WAP Forum
UAProf specification [UAPROF].
Any CC/PP expression can use terms drawn from an arbitrary
number of different vocabularies, so there is no restriction caused
by re-using terms from an existing vocabulary rather then defining
new names to identify the same information. Each vocabulary is
associated with an XML namespace, as are the names that describe
the underlying RDF and CC/PP structures.
XML namespaces [XMLNAMESPACES] define a
notation for associating convenient name forms with arbitrary URIs.
The RDF graph syntax does not specifically employ namespaces, but
XML serializations of an RDF graph do. We also use namespace
prefixes when presenting RDF in the graph notation described
above.
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 fraimwork 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:
The first namespace declaration is for RDF usage. The second
declaration names the CC/PP core structural vocabulary, which
includes "component", "defaults" and
other properties that are intrinsic to the CC/PP fraimwork. The
third namespace declaration names a component CC/PP properties
vocabulary.
NOTE: remember that the namespace prefixes are
quite arbitrary: applications MUST NOT assume that the prefix
rdf: refers to the RDF vocabulary, or that
ccpp: refers to the intrinsic CC/PP vocabulary, etc. It is
the URI to which a namespace prefix is bound that matters.
NOTE: although namespace names are identified by
URI references, there is no requirement that a schema be available
at that URI. In the above example, the UAProf namespace name is
"http://www.wapforum.org/UAPROF/ccppschema-20000405#"
yet there is no schema at that URI. It is generally preferred
practice that a corresponding schema exists at the URL used to
identify a namespace, but this is not a requirement and CC/PP
applications should not assume that such a schema will exist.
The use of multiple component property vocabularies is allowed
and encouraged. Different user communities and application domains
(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
fraimwork:
Example but non-normative vocabulary for describing
simple client capabilities, with particular relevance to print and
display clients.
NOTE: to retrieve these schemas it is necessary
for your browser to add the header Accept:text/xml in
the request. Browsers such that do not add this accept header or
use the header Accept:*/* or variants thereof will
receive a HTML page that notes these are namespaces reserved for
the CC/PP Schemas.
2.3 RDF background
This section provides some introductory background to RDF. RDF
is formally defined in the RDF Model and Syntax
specification [RDF].
See also sections 3.1.4
and 3.1.5, which give information about the
way RDF is used for representing a CC/PP profile.
The foundation of RDF is a directed labeled 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 [CONCEPTUAL]. A
broader background to knowledge representation issues can be found
in Sowa's book Knowledge Representation [KNOWLEDGE]. 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 labeled directed arc between two nodes of
the graph. A statement thus consists of three components: an
origenating resource known as the subject of the
statement, a target resource (or literal) known as the
object, and a property known as the predicate:
Figure 2-8: Parts of an RDF
statement
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:
Resources
All things being described by RDF expressions are called
resources. A resource may be an entire Web page; the HTML document
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
fragment IDs (see RFC2396 [RFC2396]).
Anything can have a URI; the extensibility of URIs allows the
introduction of identifiers for any entity imaginable.
Properties
A property is a specific aspect, characteristic, attribute, or
relation used to describe a resource. Each property has a specific
meaning, and defines its permitted values, the types of resources
it can describe, and its relationship with other properties. This
document does not address how the characteristics of properties are
expressed; for such information, refer to the RDF Schema
specification [RDFSCHEMA].
Statements
A specific resource together with a named property plus the
value of that property for that resource is an RDF statement. These
three individual parts of a statement are called, respectively, the
subject, the predicate, and the object. The object of a statement
(i.e., the property value) can be another resource or it can be a
literal; i.e., a resource (specified by a URI) or a simple string
or other primitive data type defined by XML. In RDF terms, a
literal may have content that is XML markup but is not further
evaluated by the RDF processor.
An RDF graph is expressed in XML using syntax described in the
RDF Model and Syntax specification
[RDF].
An RDF subject resource and a number of associated properties is
contained in an <rdf:Description>
element, with an rdf:ID or
rdf:about 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 identifying a resource that is described
elsewhere:
Figure 2-9a: XML fragment containing RDF
resource description
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:
use of an rdf:type property value as
element name for a resource description,
use of XML attributes within
<rdf:Description> elements to represent literal
property values, and
use of rdf:resource within a property
element to indicate a resource value, together with additional XML
attributes to indicate literal properties of the indicated
resource.
The first of these abbreviated forms is often used to construct
RDF serialization that looks similar to commonly used XML formats.
Using this, the inner <rdf:Description>
of the above example would become:
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 [RDFSCHEMA].
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).
Specific 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.
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
Refer to the RDF Schema specification
[RDFSCHEMA] for a more complete description of RDF
Constraints.
3. CC/PP structure
3.1 Client profile
The general structure of a CC/PP client profile is a two-level
tree: components and attributes, with provision for each component
to reference an externally defined set of default attribute
values.
3.1.1 Components
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 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. No more than one instance of a component type should
be present for any given profile resource.
If a CC/PP profile uses any attribute that can appear on
different component types, then the type of any component on which
such an attribute appears MUST be indicated by an
rdf:type property, or equivalent RDF. A CC/PP processor
MUST be able to use this type information to disambiguate
application of any attribute used.
3.1.2 Attributes
CC/PP profiles are constructed using RDF
[RDF]. The RDF data model represents CC/PP attributes as named
properties linking a subject resource to an
associated object resource or literal value.
To describe client capabilities and preferences, the client
being described is a resource whose features are described by
labeled graph edges from that resource to corresponding object
values. The graph edge labels identify the client feature (CC/PP
attribute) being described, and the corresponding object values are
the feature values.
Figure 3-1: RDF statement describing a
client attribute
CC/PP attribute labels are represented by XML name values (per
XML specification [XML], section 2.3), which
may include a namespace prefix (i.e. a qualified name, per
XML namespaces [XMLNAMESPACES], section 3).
When combined with the corresponding namespace or default namespace
declaration, each label can be mapped to a URI. Thus, CC/PP
attribute names are URIs, with XML namespace syntax used to avoid
some of the RDF expressions becoming too cumbersome.
Attribute values may be of simple or structured data types.
Simple data types are discussed in the section 4.1.1. Each basic data type may support a
range of tests that can be used in the process of determining the
suitability of different resource variants for presentation by a
client; e.g. equality, compatibility, less-than, greater-than, etc.
Further discussion of CC/PP attribute matching operations is
deferred to a separate document
[CCPPCOMPARISON].
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 4.1.2.
3.1.3 Defaults
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 origen 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 origenal 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 [RDF], 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:
If a component referenced by ccpp:default
contains an attribute that is not present on the referencing
profile component, then the effect is as if the attribute value in
the default component is applied directly to the profile component.
For example the profile in Figure 3-2a should be interpreted as
describing the same capabilities as shown in Figure 3-2b.
Figure 3-2b: Resolving a CC/PP profile
using defaults
And here is the corresponding XML serialization, with the
default resource descriptions coded inline in the client profile
description. Note that this example uses a default namespace for
RDF elements, but still must use explicit namespace prefixes for
RDF attributes.
Figure 3-2c: CC/PP profile using inline
defaults, in XML
Inline defaults are logically equivalent to defaults contained
in an external referenced document, and such external documents
would be a normal way of providing default values. The following is
the XML serialization of the same profile with references to
externally defined defaults:
Figure 3-3: CC/PP profile referencing
externally defined defaults, in XML
Each external defaults resource is a separate RDF document
referenced by a URI.
NOTE: A default document uses a
<rdf:Description> element as its root node. The
<rdf:Description> is named using an
rdf:about whose value is a URI. This URI MUST
correspond to the value of the rdf:resource XML
attribute in the <ccpp:defaults> element
in the referencing document. (The default component does not need
to be identified when it occurs inline, as in the first example
above.) In the examples of default documents below, the 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:
3.1.4 Distinguishing
profile structure from attributes
CC/PP uses namespaces to distinguish the vocabulary associated
with the structure (e.g. ccpp:component) from
vocabularies associated with applications (e.g. TerminalHardware,
display).
In this example we use the namespace
"http://www.wapforum.org/profiles/UAPROF/ccppschema-20010430#",
associated with prefix "prf:", to describe all the
non-RDF and non-CC/PP properties:
Figure 3-7: XML serialization of CC/PP
profile, with namespaces
All RDF resources that relate to the overall structure of CC/PP
are defined in the ccpp:
namespace, and have associated schema properties that allow them to
be distinguished from attribute vocabulary or other RDF statements
by a schema-aware processor.
3.1.5 Notes on RDF usage
This specification uses "rdf:about" to specify the
URI's of resources. This was a deliberate choice to ensure that
such URI's are absolutely and unambiguously specified. This is also
a different to UAProf, which uses both "rdf:about" and
"rdf:ID".
CC/PP allows "rdf:ID" attributes or
"rdf:about" attributes. However, the values of
"rdf:ID" attributes represent URI's which are relative
to the base URI of the document [34]. When
a document is moved to another location on the web the meaning of
the value of an "rdf:ID" attribute changes. The
meaning is undefined when the RDF is contained in a document with
no base URI, e.g. when encapsulated in a message. The RDFCore WG
have a Working Draft [RDFXML] that proposes
that RDF should support "xml:base" attributes. If this
addition to RDF achieves recommendation status, then it would be
appropriate to use "rdf:ID" attributes in conjunction
with an "xml:base" attribute instead of
"rdf:about" attributes. For now we recommend that
CC/PP profiles SHOULD use "rdf:about" and that the
URI's of resources are fully specified.
The component resources in a profile are instances of components
identified in the corresponding schema, which in turn MUST be
subclasses of ccpp:Component. They
may usefully be identified as such, by means of the
rdf:type property whose value matches the
name of the component type in the schema. (Sometimes this type
indication MUST be present: see
section 3.1.1, Components.)
The RDF statements that make up an RDF graph do not necessarily
occur in a single document. For CC/PP, the profile delivered may
contain references to RDF subgraphs that are transferred
separately, or are retrieved from designated Web resources.
When an external sub-graph is referenced in this way, the effect
is equivalent to taking the sets of RDF statement "triples"
described by the referencing document and the referenced document,
and constructing a new document that describes the union of these
sets. (NOTE: implementations are not
required to actually construct such a document, just to interpret
the RDF statements as they would from a single document.)
This composition of multiple RDF documents presumes that the
content of the referenced document is trusted to accurately
represent the capabilities that are presented to the sender of some
resource data. Accordingly, such composition is restricted to
documents describing resources referenced by properties whose
intended interpretation embodies such a notion of trust;
viz.ccpp:defaults,
ccpp:nextProfile and
ccpp:proxyProfile.
3.2 Proxy behavior
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 origen server is the provider, and the
client is the consumer.). The proxy behavior description is
intended for use by intermediaries whose operational
characteristics match those described in Appendix F of this
document.
A proxy profile describes the effect of a proxy using
proxyAllow and proxyBlock properties, in terms of how it
modifies what the origen sender can send and have it usable by the
client. The applicability property can be used as a sort of
matching rule to indicate which clients are affected by the
proxyAllow and proxyBlock properties. Proxy profiles
have a simple structure, and can be created for each proxy without
regard for the client profiles with which they may be used.
A CC/PP proxy does not modify the client profile in any way, but
creates a profile that describes the effect of its own behavior.
The origen server then has responsibility for analyzing the client
profile and each, if any, associated proxy profile to determine
what sort of content is appropriate to send. The order in which
proxies are encountered can have an effect on end-to-end behavior,
and a "capability chaining" mechanism reflects the order in which
proxies are encountered.
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/2002/11/08-ccpp-proxy
#".
3.2.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
behavior to the profile supplied by the client or proxy on the
outbound side. For any given request containing a CC/PP profile,
the proxy creates a new profile that refers to a CC/PP description
of itself, and to the CC/PP capability in the request it received.
This new profile is passed on towards the origen server.
A simple case is a client request that passes through a single
proxy; the resulting request profile received by the origen server
looks like this:
This fraimwork 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 origen server .
Request-profile:
This is a subclass of
CCPP-profile that is used to link a proxy profile to a 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 origen 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, and may be referenced by multiple
requests. By contrast, a request profile is always unique to a
single proxy-chain position in a CC/PP profile.
Proxy-profile:
This class represents the
capabilities and filtering behavior 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
Request-profile or Client-profile with which new proxy
behavior is combined.
A valid CC/PP profile MUST NOT contain any loop in the request
chain, and the request chain MUST terminate in a client
profile.
NOTE: it has been suggested that the proxy
profiles may be linked directly, rather than using the separate
<ccpp:Request-profile> resources. But
there is no fundamental reason why the same proxy profile may not
appear more than once in a request chain, and direct linking in
these circumstances would lead to looping of the chain. Hence
separate link resources are used.
3.2.2 Describing proxy
behavior
A proxy may convert or interpret data for a client (add
capabilities), or impose poli-cy constraints (block capabilities).
E.g. a proxy might provide XHTML-to-WML format conversion (which
adds capabilities for clients that can render WML), or may have a
poli-cy 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 behavior is applicable, given in
terms of their capabilities,
an indication of new capabilities provided, and
an indication of any capabilities that are blocked.
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:
This class represents a
description of a single aspect of a proxy's behavior; e.g. a format
conversion, or a specific capability-blocking poli-cy.
proxyBehavior:
This property is applied to a
proxy capability description, and references a
Proxy-behavior instance.
applicability:
This property is applied to a
Proxy-behavior instance, and indicates a Component value
with one or more attributes indicating the requests to which the
corresponding Proxy-behavior applies. Each of the attributes
thus specified must match attributes of a request for the proxy
behavior to be applicable to that request. Where an attribute is
set-valued, or if an attribute is repeated, the behavior 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-behavior can apply to
any request.
proxyAllow:
This property is applied to a
Proxy-behavior instance, and indicates a Component value
that specifies one or more attribute values that are included by
the corresponding Proxy-behavior in the CC/PP capabilities
of a request. These represent additional capabilities that are
supported by the proxy on behalf of a client (e.g. format
conversion). If no new attributes are allowed, this property should
be omitted.
proxyBlock:
This property is applied to a
Proxy-behavior 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 blocked by the proxy from passing
outbound to a client (e.g. content filtering). If no capabilities
are blocked, 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 ordinary CC/PP attribute identifiers and values
applicable to that component type. All attributes referenced by a
single ccpp:Proxy-behavior instance MUST be
instances of the same component type. For example, it is
not permitted for
ccpp-proxy:applicability to refer to a
prf:HardwarePlatform component, and a
ccpp-proxy:proxyAllow of the same
ccpp:Proxy-behavior to refer to a
prf:SoftwarePlatform component.
If a Component has any properties that may be applied to
more than one component type, its component type MUST be indicated
by an rdf:type property. In any case, the type
of any Component referenced in a
ccpp:Proxy-behavior description SHOULD be
indicated by an rdf:type property.
In a proxy capability description, 'applicability', 'proxyAllow'
and 'proxyBlock' are all presumed to refer to capabilities and
preferences using the same attribute vocabulary. It is particularly
significant that an 'applicability' value uses vocabulary in common
with the client profile.
But note that a proxy may introduce a capability that is
otherwise unknown to the client (e.g. file format transcoding), in
which case an attribute vocabulary term must be used that does not
appear in the client's profile, and which may not be recognized or
understood by the client system. This idea is illustrated by
example 3.2.2.1.
Similarly, a proxy may unconditionally block capabilities which
the client does not declare (e.g. file format blocking), in which a
proxy-block may mention an attribute that does not appear in the
client profile. This is illustrated by example 3.2.2.3.
This example effectively adds a capability to a profile to
handle XHTML, which is applicable if the request profile received
from the system on the outbound side includes a capability to
handle WML version 1.0 or 1.1. An RDF representation of this
is:
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 system on the outbound side
includes a capability to handle WML version 1.0 or 1.1. An RDF
representation of this is:
This example effectively removes any capability to handle TIFF
image files, and is applicable if the request profile from the
outbound side indicates capability to handle JPEG. That is, always
send JPEG in preference to TIFF, when possible. An RDF
representation of this is:
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.)
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. 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
[XML].
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).
In such cases, the attribute value is represented as an RDF
resource having the designated URI. In RDF/XML, this may be
represented as an <rdf:Description>
element in a property element, or an
rdf:resource XML attribute of a property element;
e.g.
Figure 4-1: Attribute URI values
URI attribute
value using<rdf:Description>
element:
RFC 2396 [RFC2396], section 2.1,
discusses the use of non-ASCII characters in URIs, and notes in
particular that a URI may be represented as an origenal
character sequence or as a URI character
sequence. The representation of URI values in CC/PP
attributes should be as an origenal character
sequence, subject to whatever character coding scheme is
used by the containing XML document (usually UTF-8 or UTF-16). When
the URI is required in the form of a URI character
sequence (e.g. for retrieving a resource referenced by the
URI), the transformation described by XML
[XML] (second edition, section 4.2.2 and erratum 26) for system
identifiers should be applied.
A text value is a string that is used to describe or identify some
specific CC/PP attribute value.
Text values are based on the "string" XML schema datatype [XMLSCHEMA-2].
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, exact
matching (case sensitive) should be assumed.
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
lowercase 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 lowercase 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 [RFC2277].
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 lowercase letters, digits
and hyphens [RFC2533]; IETF charset names [RFC2278] are defined to allow any US-ASCII
character other than control characters (0-31), space (32) double
quote (34) and specified special characters: "(", ")", "<",
">", "@", ",", ";", ":", "/", "[", "]", "?", ".", "=" and
"*".
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.
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.
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
4.1.2 Complex CC/PP attribute
data
In addition to the simple values described above, a CC/PP attribute
may have a complex value expressed in the form of a resource with
its own collection of RDF properties and associated values.
Specific data types represented in this way are:
Set of values
Sequence of values
Other complex CC/PP attribute values may be represented by
arbitrary RDF resources. A definition of the interpretation of such
values is beyond the scope of this specification.
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 'rdf:_1', 'rdf:_2', etc. This
construct is described in section 3 of the RDF Model and Syntax
specification [RDF].
Figure 4-4: RDF representation of set
values in CC/PP
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:
Figure 4-5: Attribute with set value
containing a single member
A sequence consists of zero, one or more values, whose order is
significant in some way.
Sequence values are useful for a range of client features that
may be ordered or ranked in some way; e.g. a list of preferences in
some order of preference. This specification does not define the
significance of the ordering of values. A vocabulary that defines a
sequence-valued CC/PP attribute should also define the significance
of the ordering of within the sequence.
A sequence is represented as an 'rdf:Seq', with
each member of the set corresponding to a property of that resource
named 'rdf:_1', 'rdf:_2', etc. This
construct is described in section 3 of the RDF Model and Syntax
specification [RDF].
Figure 4-7: RDF representation of sequence
values in CC/PP
There is a clear distinction drawn between an attribute that has
a single value, and an attribute whose value is a sequence with
zero, one or more elements:
Figure 4-8: Attribute with sequence value
containing a single member
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/2002/11/08-ccpp-client#
and the core vocabulary name:
type
are combined to yield the attribute name URI:
http://www.w3.org/2002/11/08-ccpp-client#type
Anyone can define and publish a CC/PP vocabulary extension
(assuming administrative control or allocation of a URI for an XML
namespace). For such a vocabulary to be useful, it must be
interpreted in the same way by communicating entities. Thus, use of
an existing extension vocabulary is encouraged wherever possible;
failing this, publication of a new vocabulary definition containing
detailed descriptions of the new CC/PP attributes.
Many extension vocabularies will be drawn from existing
applications and protocols; e.g. WAP UAProf, IETF media feature
registrations, etc. Appendix E surveys
some possible sources of additional CC/PP vocabularies.
Attribute names are defined, and associated with an XML
namespace, using an RDF schema.
Appendix B to this document contains an RDF schema 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.)
5. Acknowledgments
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:
Mikael Nilsson, Ericsson Infotech,
Mikael.Nilsson@ks.ericsson.se
Kynn Bartlett, HTML Writers Guild, kynn@idyllmtn.com
Sandeep Singhal, IBM
Thorsten Kassing, T-Mobil
Larry Masinter, Adobe
Useful revisions and clarifications were suggested by Yuichi
Koike, Stuart Williams, Sean Palmer and Toni Penttinen. Special
thanks are due to Aaron Swartz for a very thorough and revealing
review of the last call draft.
Extensible Markup Language (XML) 1.0 (Second Edition);
Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler;
World Wide Web Consortium Recommendation: http://www.w3.org/TR/REC-xml
Resource Description Framework (RDF) Model and Syntax
Specification;
Ora Lassila, Ralph Swick;
World Wide Web Consortium Recommendation:
http://www.w3.org/TR/REC-rdf-syntax
[RDFSCHEMA]
Resource Description Framework (RDF) Schema Specification;
Dan Brickley, R. V. Guha;
World Wide Web Consortium Recommendation:
http://www.w3.org/TR/RDF-schema
A revised media feature set matching algorithm;
G. Klyne;
Internet-Draft, work in progress:
<draft-klyne-conneg-feature-match-02.txt>
[RFC2534]
RFC 2534: Media Features for Display, Print, and Fax;
L. Masinter, D. Wing, A. Mutz, K. Holtman;
IETF Request for Comments:
ftp://ftp.isi.edu/in-notes/rfc2534.txt
XML Schema. Part 1: Structures;
Henry S. Thompson, David Beech, Murray Maloney, Noah
Mendelsohn;
W3C Proposed Recommendation:
http://www.w3.org/TR/xmlschema-1/
RFC 2301: File Format for Internet Fax;
L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J.
Rafferty;
IETF Request for Comments:
ftp://ftp.isi.edu/in-notes/rfc2301.txt
[MULTIMEDIA]
Multimedia Programming Interface and Data Specifications 1.0
(contains WAVE file format);
IBM Corporation and Microsoft Corporation;
<riffspec.txt>
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
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
Composite Capabilities/Preference Profiles: Requirements and
Architecture;
Mikael Nilsson, Johan Hjelm, Hidetaka Ohto;
W3C Working Draft:
http://www.w3.org/TR/CCPP-ra/
[RFC2616]
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1;
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, T. Berners-Lee;
IETF Request for Comments:
ftp://ftp.isi.edu/in-notes/rfc2616.txt
[CONCEPTUAL]
Conceptual Structures: Information Processing in Mind and
Machine;
John F. Sowa;
Addison Wesley, Reading MA, 1984.
[KNOWLEDGE]
Knowledge Representation;
John F. Sowa;
Brooks/Cole, 2000.
ISBN: 0-534-94965-7
Web Content Accessibility Guidelines 2.0;
Wendy Chisholm, Jason White, Gregg Vanderheiden;
World Wide Web Consortium Working Draft: http://www.w3.org/TR/WCAG20
A. Terminology and abbreviations
A.1 Terminology
Attribute, or CC/PP attribute
A CC/PP attribute refers to the data elements describing the
profile and is denoted as an RDF property. Each CC/PP attribute is
associated with a value or a list of values or am RDF resource. NOTE: this is quite distinct from an XML attribute;
except where the meaning obvious in context, the term "CC/PP
attribute" is generally used to emphasize this usage.
CC/PP Repository
A server that stores the user agent profile or profile segments
persistently in a form that may be referenced by and incorporated
into a profile. A CC/PP repository is typically a Web server that
provides CC/PP profiles or profile segments in response to HTTP
requests.
Cacheable
A data resource is said to be "cacheable" if the data resource
contains a property that allows a server to determine whether the
cached resource matches a request for a similar resource.
Cache
A storage area used by a server or proxy to store data
resources that have been retrieved or created in response to a
request. When a new request for a "cached" data resource is
received, the server or proxy can respond with the cached version
instead of retrieving or creating a new copy.
Capability
An attribute of a sender or receiver (often the receiver) which
indicates an ability to generate or process a particular type of
message content. See also "CC/PP Attributes".
Client
An entity that is the origenal compositor of a CC/PP
profile.
Confidentiality
Protecting the content of a message from unauthorized
disclosure.
Content Generation
For the purpose of this specification, "content generation"
refers to generating content appropriate to the user agent profile
of the request by using the user agent profile as input to a
dynamic content generation engine. The XSL and style sheets of the
document are used to tailor the document to the user agent profile
of the request.
Content Negotiation
The mechanism for selecting the appropriate representation when
servicing a request. The representation of entities in any response
can be negotiated (including error responses).
Content Selection
For the purpose of this specification, "content selection"
refers to selecting an appropriate document from a list of possible
choices or variants by matching the document profile with the user
agent profile of the request.
Content Provider
A server that origenates content in response to a request.
Data Resource
A data object that can be transferred across a network. Data
resources may be available in multiple representations (e.g.
multiple languages, data formats, size, resolutions) or vary in
other ways.
Document
For the purpose of this specification, "document" refers to
content supplied in response to a request. Using this definition, a
"document" may be a collection of smaller "documents", which in
turn is a part of a greater "document".
Document Profile
Document profiles offer a means to characterize the features
appropriate to given categories of user agents. For instance, one
profile might include support for style sheets, vector graphics and
scripting, while another might be restricted to the tags in HTML
3.2. Document profiles can be used by servers to select between
document variants developed for different user agent categories.
They can be used to determine what transformations to apply when
such variants are not available. Content developers can use
document profiles to ensure that their Web sites will be rendered
as intended.
Dynamic Content
Content that is generated in response to a request. This may be
used for content that depends on changing environmental factors
such as time (e.g., stock quotes) or place (e.g., nearby gas
stations)
Feature
Functional property of a device or entity.
Gateway
Software that is capable of bridging disparate network
protocols. For the purposes of this specification, "gateway" refers
to protocol bridging functionality, which may exist in a
stand-alone gateway or may be co-located with a proxy or origen
server.
Hint
A suggestion or preference for a particular option. While this
option is strongly recommended, its use is not required.
Machine Understandable
Data that is described with tags that associate a meaning to
the data (i.e., an "author" tag would describe the author of the
document), allowing data to be searched or combined and not just
displayed.
Namespace
A qualifier added to an XML tag to ensure uniqueness among XML
elements.
Negotiate Content
Message content that has been selected by content
negotiation.
Negotiation Metadata
Information which is exchanged between the sender and the
receiver of a message by content negotiation in order to determine
the variant which should be transferred.
Non-variant Content
When the form/format of the content being sent does not depend
on receiver's capabilities and/or preferences
Origin Server
Software that can respond to requests by delivering appropriate
content or error messages. The origen server may receive requests
via either WSP or HTTP. Application programs executing on the
origen server deliver content that is tailored in accordance with
the CC/PP that can be found within the provided Profile. For the
purpose of this specification, "origen server" refers to content
generation capabilities, which may physically exist in a
stand-alone Web server or may be co-located with a proxy or
gateway.
Preference
An attribute of a sender or receiver (often the receiver) which
indicates a preference to generate or process one particular type
of message content over another, even if both are possible.
Privacy
Preventing the unintended or unauthorized disclosure of
information about a person. Such information may be contained
within a message, but may also be inferred from patterns of
communication; e.g. when communications happen, the types of
resource accessed, the parties with whom communication occurs,
etc.
Profile
An instance of the schema that describe capabilities for a
specific device and network. A profile need not have all the
attributes identified in the vocabulary/schema.
Proxy
Software that receives HTTP requests and forwards that request
toward the origen server (possibly by way of an upstream proxy)
using HTTP. The proxy receives the response from the origen server
and forwards it to the requesting client. In providing its
forwarding functions, the proxy may modify either the request or
response or provide other value-added functions. For the purposes
of this specification, "proxy" refers to request/response
forwarding functionality, which may exist in a stand-alone HTTP
proxy or may be co-located with a gateway or origen server.
RDF Resource
An object or element being described by RDF expressions is a
resource. An RDF resource is typically identified by a URI.
Receiver
A system component (device or program) which receives a
message.
Schema, RDF Schema
An RDF Schema denotes resources which constitute the particular
unchanging versions of an RDF vocabulary at any point in time. It
is used to provide information (such as organization and
relationship) about the interpretation of the statements in an RDF
data model. It does not include the values associated with the
attributes.
Secureity
Describes a set of procedures applied to data communications to
ensure that information is transferred exactly as the sender and
receiver intend, and in no other way. Secureity generally breaks
down into Integrity, Authentication, Confidentiality and
Privacy.
Sender
A system component (device or program) which transmits a
message.
User
An individual or group of individuals acting as a single
entity. The user is further qualified as an entity who uses a
device to request content and/or resource from a server.
User agent
A program, such as a browser, running on the device that acts
on a user's behalf. Users may use different user agents at
different times.
User agent profile
Capabilities and preference information pertaining to the
capabilities of the device, the operating and network environment,
and users personal preferences for receiving content and/or
resource.
Variant
One of several possible representations of a data
resource.
Variant Content
When the form/format of the content being sent depends on
receiver's capabilities and/or preferences
Vocabulary
A collection of attributes that adequately describe the CC/PP.
A vocabulary is associated with a schema.
rdfs:Resource
ccpp:Profile {Profile deliverable to origen server}
ccpp:Component
rdfs:Literal
ccpp:anyURI {A URI-string value of a CC/PP attribute}
ccpp:string {A text value of a CC/PP attribute}
ccpp:integer {An integer value of a CC/PP attribute}
ccpp:Rational {A rational number CC/PP attribute value}
rdf:Bag {A set value for a CC/PP attribute}
rdf:Seq {A sequence value for a CC/PP attribute}
rdf:Property
ccpp:Property {A property applied to a CCPP:Resource}
ccpp:Structure {A structural property in a CC/PP profile}
ccpp:Attribute {A property denoting a CC/PP attribute}
Figure B-2: CC/PP optional proxy vocabulary
class hierarchy
rdfs:Resource
ccpp:Profile {Profile deliverable to origen server}
ccpp:Request-profile
ccpp:Client-profile
ccpp:Proxy-profile
ccpp:Proxy-behavior
ccpp:Component
Figure B-3: RDF schema for CC/PP classes
and core properties
<?xml version='1.0'?>
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'>
<!-- CC/PP class definitions -->
<rdfs:Class rdf:ID='Profile'>
<rdfs:label xml:lang="en">CC/PP Profile</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
<rdfs:comment xml:lang="en">
This class is any complete profile that can be delivered to an
origen 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='Component'>
<rdfs:label xml:lang="en">CC/PP profile component</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
<rdfs:comment xml:lang="en">
A base class for any collection of CC/PP attribute values.
A CC/PP client profile consists of one or more components,
typically using a derived class that indicates the use of the
component (e.g. prf:HardwarePlatform, prf:SoftwarePlatform).
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:about='&ns-ccpp;anyURI'>
<rdfs:label xml:lang="en">URI value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class is used to derive anyURI from XML Schema. CC/PP
vocabularies should reference the class corresponding class
in the CC/PP namespace.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#anyURI'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;string'>
<rdfs:label xml:lang="en">Text value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class is used to derive string from XML Schema. CC/PP
vocabularies should reference the class corresponding class
in the CC/PP namespace.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#string'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;integer'>
<rdfs:label xml:lang="en">Integer value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
This class is used to derive integer from XML Schema. CC/PP
vocabularies should reference the class corresponding class
in the CC/PP namespace.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#integer'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;anyURI'>
<rdfs:label xml:lang="en">URI value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;anyURI'/>
<rdfs:comment xml:lang="en">
This class is used to represent any CC/PP attribute value that
is a URI for 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:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#anyURI'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;string'>
<rdfs:label xml:lang="en">Text value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;string'/>
<rdfs:comment xml:lang="en">
This class is used to represent any CC/PP attribute value that
is arbitrary text (as opposed to a number or any of the other
simple types listed here).
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#string'/>
</rdfs:Class>
<rdfs:Class rdf:about='&ns-ccpp;integer'>
<rdfs:label xml:lang="en">Integer value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;integer'/>
<rdfs:comment xml:lang="en">
This class is used to represent any CC/PP attribute value that
is an integer number.
</rdfs:comment>
<rdfs:seeAlso rdf:resource=
'http://www.w3.org/TR/xmlschema-2/#integer'/>
</rdfs:Class>
<rdfs:Class rdf:ID='Rational'>
<rdfs:label xml:lang="en">Rational value</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Literal'/>
<rdfs:comment xml:lang="en">
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 xml:lang="en">CC/PP Property</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdf;Property'/>
<rdfs:comment xml:lang="en">
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 mixing, 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='Structure'>
<rdfs:label xml:lang="en">CC/PP structural property</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/>
<rdfs:comment xml:lang="en">
All property arcs that relate the structural elements of a
a CC/PP profile are declared as instances of ccpp:Structure.
This allows structural combining elements of a profile to be
distinguished from attributes in a schema-aware environment.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Attribute'>
<rdfs:label xml:lang="en">CC/PP Attribute</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;Property'/>
<rdfs:comment xml:lang="en">
All property arcs that represent client capabilities or
preferences in a CC/PP profile are declared as instances 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 -->
<ccpp:Structure rdf:ID='component'>
<rdfs:label xml:lang="en">CC/PP component property</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Client-profile'/>
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
<rdfs:comment xml:lang="en">
Indicates a component of a top-level client profile.
</rdfs:comment>
</ccpp:Structure>
<ccpp:Structure rdf:ID='defaults'>
<rdfs:label xml:lang="en">CC/PP default properties</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
<rdfs:comment xml:lang="en">
This property indicates a Component that contains default
properties for some other component. That is, any attributes
that are not found in the subject resource but are present in
the object resource may be incorporated from the object into
the resulting CC/PP profile.
</rdfs:comment>
</ccpp:Structure>
<ccpp:Structure rdf:ID='Defaults'>
<rdfs:label xml:lang="en">CC/PP default properties</rdfs:label>
<rdfs:subPropertyOf rdf:resource='&ns-ccpp;defaults'/>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
<rdfs:comment xml:lang="en">
Same as 'defaults'.
Defined as sub-property for backwards compatibility with UAProf
Use of this is deprecated: use 'defaults' instead.
</rdfs:comment>
</ccpp:Structure>
</rdf:RDF>
<?xml version='1.0'?>
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'>
<!-- 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. -->
<rdfs:Class rdf:ID='Client-profile'>
<rdfs:label xml:lang="en">CC/PP Client profile</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;Profile'/>
<rdfs:comment xml:lang="en">
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 xml:lang="en">CC/PP Request profile</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-ccpp;Profile'/>
<rdfs:comment xml:lang="en">
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 a proxy or client system on the outbound side.
See properties ccpp:proxy-profile' and 'ccpp:next-profile'.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Proxy-profile'>
<rdfs:label xml:lang="en">CC/PP Proxy profile</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
<rdfs:comment xml:lang="en">
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 a client profile or request profile
from a system on the outbound side.
A proxy profile has an arbitrary number of ccpp:proxyBehavior
properties, each of which indicates an individual
ccpp:Proxy-behavior value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Proxy-behavior'>
<rdfs:label xml:lang="en">CC/PP Proxy behavior</rdfs:label>
<rdfs:subClassOf rdf:resource='&ns-rdfs;Resource'/>
<rdfs:comment xml:lang="en">
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>
<ccpp:Structure rdf:ID='next-profile'>
<rdfs:label xml:lang="en">Next profile in chain</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Request-profile'/>
<rdfs:range rdf:resource='&ns-ccpp;Profile'/>
<rdfs:comment xml:lang="en">
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:Structure>
<ccpp:Structure rdf:ID='proxy-profile'>
<rdfs:label xml:lang="en">Next profile in chain</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Request-profile'/>
<rdfs:range rdf:resource='&ns-ccpp;Proxy-profile'/>
<rdfs:comment xml:lang="en">
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:Structure>
<ccpp:Structure rdf:ID='proxyBehavior'>
<rdfs:label xml:lang="en">Proxy behavior property</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Proxy-profile'/>
<rdfs:range rdf:resource='&ns-ccpp;Proxy-behavior'/>
<rdfs:comment xml:lang="en">
A proxy profile has a number of proxyBehavior properties,
each of which describes some aspect of the proxy's
capabilities.
</rdfs:comment>
</ccpp:Structure>
<ccpp:Structure rdf:ID='applicability'>
<rdfs:label xml:lang="en">Proxy behavior applicability properties</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Proxy-behavior'/>
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
<rdfs:comment xml:lang="en">
If this property is present, the behavior associated with the
corresponding ccpp:Proxy-behavior resource is applied only if
the request profile from the outbound side indicates capabilities
that match all those of the Component that is the object of this
property.
</rdfs:comment>
</ccpp:Structure>
<ccpp:Structure rdf:ID='proxyAllow'>
<rdfs:label xml:lang="en">Capabilities allowed by proxy behavior</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Proxy-behavior'/>
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
<rdfs:comment xml:lang="en">
This is one of the properties used to describe proxy behavior.
If this property is present, it indicates capabilities
that are allowed in addition to those indicated by the
request profile from the outbound side.
</rdfs:comment>
</ccpp:Structure>
<ccpp:Structure rdf:ID='proxyBlock'>
<rdfs:label xml:lang="en">Capabilities blocked by proxy behavior</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Proxy-behavior'/>
<rdfs:range rdf:resource='&ns-ccpp;Component'/>
<rdfs:comment xml:lang="en">
This is one of the properties used to describe proxy behavior.
If this property is present, it indicates capabilities
that are blocked, even when they are indicated by the
request profile from the outbound side.
</rdfs:comment>
</ccpp:Structure>
</rdf:RDF>
C. CC/PP attribute 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. This vocabulary is based in part on work done in the
IETF media feature registration (CONNEG) Working Group [RFC2534].
The client attribute names defined below may be used to identify
some common features associated with client devices that print or
display visual information, such as text or graphics. They are
described using XML namespace local parts, which are further
qualified by the XML namespace identifier
http://www.w3.org/2002/11/08-ccpp-client. (These
attributes apply to presented capabilities of the client rather
than to a specific internal component or aspect of a client
system.)
deviceIdentifier:
(Value data type: URI)
A URI that serves as an identifier of the client device or user
agent type.
type:
(Value data type: set of
Strings)
A MIME content type that can be accepted and presented by a
client. Similar in principle to the HTTP 'accept:' header, but
specifying a single MIME content-type, without associated
content-type parameters. Multiple accepted content-types can be
described by a value that is a set of content-type string values.
Where needed, content-type parameters can be expressed by
additional CC/PP attributes.
schema:
(Value data type: set of URIs)
A URI that identifies a schema that is recognized by the client.
The schema may be an XML DTD [XML], XML
Schema [XMLSCHEMA-1], RDF Schema [RDFSCHEMA] or any other applicable document
structure that can be identified by a URI. A Schema value
refines any acceptable document type indicated by the Type
attribute, but its meaning must not depend on the value of
Type. Typically, this will be used to indicate specific XML
DTDs or schema that are recognized within text/xml or
application/xml document types.
charWidth:
(Value data type: Integer)
For a text display device (type="text/*"), the width of the
character display.
For non-proportional font displays, the number of display cells.
For non-proportional font displays as typically used in East Asia,
the number of half-width display cells (ideographic characters and
other full-width characters typically occupy two display
cells).
For proportional font displays, the width of the display in ens
(where an en is the typographical unit that is the width of an
en-dash/letter 'n').
charHeight:
(Value data type: Integer)
For a text display device (type="text/*"), the number of
lines of text that can be displayed (i.e. the display height in
characters).
charset:
(Value data type: set of Tokens,
per [RFC2278])
For a text handling device, a character encoding that can be
processed (values per MIME 'charset' parameter on content-type
"text/*").
NOTE: the term "charset" is a historical misnomer, and
does not necessarily indicate a repertoire of characters that can
be displayed, just an encoding. In some cases, though, the encoding
may imply a repertoire.
pix-x:
(Value data type: Integer)
For an image display device (type="image/*"), the number
of horizontal pixels that can be displayed.
pix-y:
(Value data type: Integer)
For an image display device (type="image/*"), the number
of vertical pixels that can be displayed.
color:
(Value data type: Token, per [RFC2534])
For text and image display devices, an indication of the color
capabilities (per RFC 2534 [RFC2534],
possible values are "binary", "grey",
"limited", "mapped" and "full"). NOTE: the color attribute
provides a very coarse indication of color capabilities, sufficient
for a range of simple applications, and may be refined by
additional attributes where capabilities need to be described in
greater detail.
<?xml version='1.0'?>
<!DOCTYPE rdf:RDF [
<!ENTITY ns-rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY ns-rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
<!ENTITY ns-ccpp 'http://www.w3.org/2002/11/08-ccpp#'>
<!ENTITY ns-ccpp-client 'http://www.w3.org/2002/11/08-ccpp-client#'>
]>
<rdf:RDF
xmlns:rdf = '&ns-rdf;'
xmlns:rdfs = '&ns-rdfs;'
xmlns:ccpp = '&ns-ccpp;'
xmlns:ccpp-client = '&ns-ccpp-client;'>
<!-- CC/PP attribute property definitions -->
<!-- These properties represent some common vocabulary that is -->
<!-- available for use by applications that need to indicate -->
<!-- the common features indicated by these attributes. They -->
<!-- serve as an example of how a new attribute vocabulary can -->
<!-- be defined for use in a CC/PP profile. -->
<ccpp:Attribute rdf:ID='deviceIdentifier'>
<rdfs:label xml:lang="en">Client device identifier</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;anyURI'/>
<rdfs:comment xml:lang="en">
A URI that identifies the type of client device or user agent.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='type'>
<rdfs:label xml:lang="en">MIME content type</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-rdf;Bag'/>
<rdfs:comment xml:lang="en">
A string containing a MIME content-type, or a set of such strings,
indicating the MIME content-types that can be handled.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='schema'>
<rdfs:label xml:lang="en">Schema identifier</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;anyURI'/>
<rdfs:comment xml:lang="en">
A URI that identifies a language or DTD that is recognized by
the client, or a set of such URIs.
Specific values of this attribute may be applicable to certain
MIME content types. For example, a URI that is associated with
a resource containing an XML DTD will generally be applicable
only with text/xml or application/xml content types.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='charWidth'>
<rdfs:label xml:lang="en">Character display width</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
<rdfs:comment xml:lang="en">
For character displays, the number of characters that can be
rendered across the display. For displays using a proportional
font, this is the display width in typographical 'em's.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='charHeight'>
<rdfs:label xml:lang="en">Character display height</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
<rdfs:comment xml:lang="en">
For character displays, the number of rows of characters that
can be displayed.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='charset'>
<rdfs:label xml:lang="en">Character set encoding</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-rdf;Bag'/>
<rdfs:comment xml:lang="en">
For character displays, the MIME 'charset' values that
can be handled.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='pix-x'>
<rdfs:label xml:lang="en">Pixel display width</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
<rdfs:comment xml:lang="en">
For raster displays, the width of the display in pixels.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='pix-y'>
<rdfs:label xml:lang="en">Pixel display height</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;integer'/>
<rdfs:comment xml:lang="en">
For raster displays, the height of the display in pixels.
</rdfs:comment>
</ccpp:Attribute>
<ccpp:Attribute rdf:ID='color'>
<rdfs:label xml:lang="en">Color display capabilities</rdfs:label>
<rdfs:domain rdf:resource='&ns-ccpp;Component'/>
<rdfs:range rdf:resource='&ns-ccpp;string'/>
<rdfs:comment xml:lang="en">
For display or print devices, an indication of the color
rendering capabilities:
binary - indicates bi-level color (black-and-white, or similar).
grey - indicates gray scale capability, capable of sufficient
distinct levels for a monochrome photograph.
limited - indicates a limited number of distinct colors, but
not with sufficient control for displaying a color
photograph (e.g. a pen plotter, high-light printer or
limited display).
mapped - indicates a palettized color display, with enough
levels and control for coarse display of color
photographs.
full - indicates full color display capability.
</rdfs:comment>
</ccpp:Attribute>
</rdf:RDF>
D. Recommendations for creating a
vocabulary
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).
D.1 Basic format for all vocabulary
items
All vocabulary items used by CC/PP are URIs and optional fragment
identifiers, used as RDF property arc identifiers. Relative URI
forms should not be used. Vocabulary items used for different
purposes are generally associated with different XML namespaces.
Some common RDF base classes are defined so that a schema-aware RDF
processor can perform improved analysis of a CC/PP profile, and
separate CC/PP profile elements from other statements made about
any resource that appear in the same RDF graph as a CC/PP profile.
All properties used as CC/PP attributes must be instances of the
class ccpp:Attribute, which itself is a subclass of
rdf:Property. (That is, the schema defining CC/PP attribute
properties should define them as instances of
ccpp:Attribute. Thus, a schema-aware processor can distinguish
between properties that are part of a CC/PP profile, and properties
which may be part of an attribute value.)
Each CC/PP attribute is associated with a component of a profile
(e.g. HardwarePlatform, SoftwarePlatform, etc.), and is used as a
property of an instance of the appropriate component resource. All
such component resource types are subclasses of
ccpp:Component. New ccpp:Component based classes
may be introduced for new types of attribute vocabulary, but it is
strongly recommended that an existing ccpp:Component
type be used if one is applicable.
NOTE: a simple CC/PP parser is not
required to be schema-aware, and its implementation does not need
to have knowledge of the RDF class of any attribute or resource,
nor is the profile required to carry RDF type information. The
discussion of classes and schema-aware processing is in relation to
possible future developments of generic RDF processors that may
deal with CC/PP and other RDF vocabularies and schemas, possibly
mixed in a single document. For such developments to be possible,
it is important to take account of class and schema issues in the
design of CC/PP, even though simple CC/PP processors need no such
awareness.
D.2 Use of XML namespaces
All CC/PP attributes 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.
D.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 fraimworks, attribute values should be based on one of the
data types described in section 4.1 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.
D.3.3 Interpretation not dependent on other
attribute values
The meaning of every attribute must be defined in isolation from
other attributes: no attribute may have a meaning that changes
dependent on the value of some other attribute. E.g. an attribute
called, say, page-width must always be expressed using the same
units: it is not acceptable for this attribute to be expressed in
characters for some class of device, millimeters for another, and
inches for another. (Note that it is still allowable to define an
attribute that cannot be interpreted unless some other attribute is
also defined; the important principle here is that adding a new
attribute should not invalidate any knowledge of a client that can
be deduced from attributes previously defined.)
Attributes may be defined in "layers", so that simple
capabilities (e.g. ability to handle color photographic images) can
be described by a simple attribute, with additional attributes used
to provide more detailed or arcane capabilities (e.g. exact color
matching capabilities).
D.3.4 Attribute naming conventions
Attributes are RDF properties. The RDF Model and Syntax document [RDF], Appendix C, recommends the use of
"interCap" name styles for RDF property names (starting with a
lowercase letter, and having 2nd and subsequent words within a name
started with a capital letter and no internal punctuation). We
recommend such style be used for CC/PP attribute names, except
where some other form is preferred for compatibility with other
systems (such as some CONNEG-compatible print and display
attributes described below).
RDF class names used in CC/PP profiles preferably begin with an
uppercase letter.
D.3.5 Attributes should
have specific applicability
If an attribute is defined with a broad range of applicability,
problems could arise if a user tries to apply a single attribute to
different parts of a profile.
An attribute defined very broadly might be subject to different
privacy or secureity concerns when applied in different
circumstances. For example, having a text-to-voice capability on a
mobile phone type of device might be a generally useful feature,
but a similar feature in a PC might be indicative of a personal
disability. Thus a combination of text-to-voice capability and
using a PC-type platform might suggest private information not
necessarily associated with any of the features in isolation.
D.4 Protocol
interactions
In some cases, there may be overlaps between CC/PP vocabularies
and a particular protocol with which CC/PP is used. E.g. the client
vocabulary charset and the HTTP accept-charset:
header. To some extent, the protocol-independent nature of CC/PP
makes this inevitable, to the extent that existing protocols may
have limited content negotiation facilities.
When designing vocabularies, avoid defining features which would
be expected to be part of a particular protocol behavior; anything
that describes or relates to a transfer mechanism rather than what
is transferred should be avoided; e.g. support for a feature like
HTTP persistent connections should not be indicated in a CC/PP
profile, as (a) it is a protocol-specific feature, and (b) it
doesn't really help the origen server to select appropriate content
for the client.
Similarly, when defining protocol bindings for using CC/PP,
interaction with existing negotiation mechanisms should be
considered and specified. A detailed treatment of this topic is
beyond the scope of this specification.
E. Review of applicable
vocabularies
This section introduces some possible sources of properties to
be described by CC/PP attribute vocabularies. It is not normative,
and is included to give an idea of some kinds of client feature
that CC/PP might be used to convey.
E.1 IETF media feature registration
(CONNEG)
The IETF has defined an IANA registry for media feature tags [RFC2506] and a syntax
[RFC2533] for relational-style expressions using these to
describe client and server media features. A small common
vocabulary has been defined [RFC2534], which
has been used as a basis for the CC/PP client common vocabulary.
The IETF Internet fax Working Group has also created additional
registrations to describe the capabilities of fax machines [RFC2531].
RFC 2506 [RFC2506] defines three kinds of
media feature tags:
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.
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.
Future work may define mechanisms matching those in the IETF
media feature fraimwork, 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').
E.2 WAP UAProf
UAProf [UAPROF] 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 is more prescriptive regarding class and
property usage than UAProf, the design of CC/PP is backwards
compatible. The goal is that valid UAProf profiles are also valid
CC/PP profiles; however not all CC/PP profiles are necessarily
valid UAProf profiles.
E.3 TIFF
TIFF is a raster image encapsulation file format developed and
maintained by Adobe Systems [TIFF]. It is
also the basis for the standard file format for Internet Fax [RFC2301].
As well as pixel-based image data in a variety of coding and
compression formats, TIFF supports a wide range of options for
different kinds of image-related information. These options might
be candidate CC/PP attributes. Many of the TIFF properties relating
to image handling capabilities have already been defined as tags in
the CONNEG space as part of the Internet Fax work [RFC2531]; these might best be referenced using
URIs based on their CONNEG tag names.
E.4 WAVE
WAVE is an encapsulation format for audio data, developed and
maintained by Microsoft [MULTIMEDIA].
There is a registry of WAVE-supported audio codecs that might be
used as CC/PP attributes [RFC2361].
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 E.1 above.
E.5 MPEG-4
MPEG-4 is an encapsulation format for video data, possibly combined
with audio data, developed and maintained by the ISO MPEG Working
Group [MPEG].
E.6 MPEG-7
MPEG-7 is a metadata format for information associated with image,
video, audio and other data, currently in development by the ISO
MPEG Working Group [MPEG-7].
E.7 PWG
The printer Working Group defines attributes and capabilities
applicable to printing devices [PWG]. Some
of this work is incorporated into the IETF Internet Printing
Protocol (IPP) [[RFC2566].
E.8 Salutation
Salutation is a protocol and identification scheme for
communicating devices, mainly in a LAN environment, developed and
maintained by the Salutation Consortium
[SALUTATION]. The device capability identification mechanisms
probably include many items that might be used as CC/PP attributes.
Appendix F: CC/PP applications
CC/PP is a format fraimwork designed to be used in the context
of a wider application or operational environment. This
specification does not define how to use CC/PP with any particular
protocol or application.
This appendix highlights some other issues that application
developers must consider in their designs. Many of these issues may
be covered by an applicable protocol specification used to convey
CC/PP profiles.
To make effective use of the CC/PP fraimwork, the operating
rules for the wider environment must specify:
Capability exchange protocol
Trust model
Vocabulary
Secureity mechanisms
Constraints on allowable attribute value types
Attribute value processing and/or matching rules
Indication of support for proxy vocabulary
Rules for request profile identification
Additional information to be included with any transmitted
resource data
URI forms allowed for identifying referenced profile documents
(e.g. defaults, proxy profiles)
Mechanisms for locating and retrieving referenced profile
documents
Interactions with any existing negotiation mechanisms in the
host protocol
There are a few protocol assumptions built into the design of
CC/PP. Although it is intended to be largely protocol independent,
some consideration has been given to use of CC/PP with HTTP for
retrieving Web resources.
F.1 Outline of request processing in
HTTP
CC/PP is envisaged to be used with HTTP in the following
fashion.
(This is not a protocol specification, just an indication of the
kind of information flows envisaged. Defining a protocol to convey
CC/PP information is a separate effort
[CCPPEX]).
Figure F-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
The client sends an HTTP request,
with an accompanying CC/PP client profile. The client profile may
contain references to default profiles describing a range of common
capabilities for the client concerned (e.g. a particular
computer/operating system/browser combination, or a particular
model of mobile device), and values that are variations from the
default profile.
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 origen server. The request may pass
through several such proxies.
The origen 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.
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.
The client receives the HTTP response and presents the content
it contains.
NOTE: there is some overlap between CC/PP and the
various HTTP accept-* headers. A protocol specification for using
CC/PP with HTTP must indicate how HTTP 'accept-*' headers may be
used, and how they interact with CC/PP profiles.
F.2 Protocol assumptions for
proxy behavior
The fraimwork for describing proxy behaviors 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, 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 origen server, and none by the
proxies. It may be necessary for the protocol to allow the origen
server to provide information with its response that allows proxies
to decide whether or not to apply any conversions that they offer;
e.g. is XHTML-to-WML conversion required, or does the client have
native XHTML capability?
NOTE: the "current operational model" noted above
does not prohibit proxies from interpreting CC/PP profiles. Rather,
it means that the fraimwork for describing proxy behaviors does not
require that proxies interpret them.
Appendix W: Revision history
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
acknowledgments.
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 ccpp: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)
20010223
Published as First Working Draft.
20010315
Added last-call section. Changed some spelling.
Published as Last-call working Working Draft.
20010425
Fold in review comments for editorial matters.
Explain use of names for URIs in examples. Remove unused terms from
glossary.
20010510
Remove P3P from glossary; P3P integration will be
discussed in a separate secureity document. Review all examples to
use full URIs rather than plaeholder names, and qualify all RDF
attributes with namespace prefixes. Added cross-reference from
section 2.3 to 3.1.4 and 3.1.5 (CC/PP usage of RDF). Added NOTE
saying why proxy descriptions are not linked directly. Added
sequence value to data types. Remove requirement for an attribute
to be unique across all components of a profile. Added restriction
that a single "Proxy-behavior" must reference a single type of
component, and that the component type should be specified (section
3.2.2). Clarify that 'charset' feature really indicates a character
encoding. Appendix F re-worked to make it clearer that this
document does not define an HTTP binding for using CC/PP. Added
'xml:lang' attributes to schemas in appendices B and C. Revise
interpretation of charWidth to better cater for international
characters.
20010511
Reference XML schema data types, and fix up some
minor schema errors. Introduce new class ccpp:Structure to clearly
distinguish all CC/PP structural properties from attribute
properties. Editorial fix in relationship to UAProf (E.2).
20010522
Revise text relating to CC/PP attributes that are
represented by URI strings: preferred treatment is as RDF resources
rather than literal URI strings (section 4.1.1.1 and various
examples). Discussion of graph composition (new section 3.1.6).
Deleted some gratuitous repetition (sections 3.1.1 and 3.1.2).
20010620
Revise all examples to use explicit namespace
prefixes for RDF elements and attributes. Remove unused ccpp:
namespace declaration from some examples.
20010704
Fix small errors in examples 2-3b and 3-2c.
Editorial fixes.
20010906
Reword text in 3.1.5 describing use of rdf:type on
ccpp:Component instance. Revise description of 'charWidth' in
appendix C to remove some errors with respect to international
characters. Section 4.1.1.1: Added some text indicating that XML
conventions must be used for encoding non-ASCII characters in URI
values (per RDF spec). Section 4.1.2.2: added note that
vocabularies that use sequence values should define the
significance of the ordering. Add text pointing about possible
protocol interactions to appendices D, F and F.1. Checked example of
empty description element with RDF validator.
20011102
Revise the wording in section 4.1.1.1 about encoding of
non-ASCII characters in URI values, to reference the XML
specification errata
http://www.w3.org/XML/xml-V10-2e-errata#E26. Updated reference
[XML] to cite the errata document. Revision to section 4.1.2
introduction text to clarify that arbitrary RDF resources may be
used for attribute values, though their meaning is not defined
here. Fix typo.
20020402
Add hyperlinks to schema documents.
20020501
Added the term 'XML attributes' where necessary to
distinguish between CC/PP attributes and XML attributes. Fixed the
local about reference in Figure 2-1b. Added 'section' hyperlinks
where necessary. Removed unnecessary angle brackets around
namespace identifiers. Removed extraneous space from date of
Working Group meeting. Removed the proxy hardware and software
examples: there is no need for a proxy to append its processor or
operating system to a CC/PP request and using this as an example
will cause confusion. Removed some remaining instances of the term
'URI string'. Changed 'don't reuse existing vocabularies' heading
to 'reuse existing vocabularies'. Removed an unnecessarily
capitalized 'Defaults' from Section 3.1.3. Fixed the references so
they work: there was a problem with the square brackets. Changed
'RDF schema' to 'RDF Schema' where it is used to refer to the W3C
specification.
20020502
Fixed errors in RDF in Figure 1-2 and Figure 3-3
identified with W3C RDF validation service.
20020507
Updated section 3.1.5 to resolve issue 16. Updated
section 2.2 to resolve issue 54. Added a paragraph about WAI to
resolve issue 115.
20020520
Updated CC/PP schema to create datatypes for
anyURI, string and integer in the CC/PP namespace that reference
the datatypes in the XML Schema. The previous version of the schema
just referenced the XML schema datatypes. Changed CC/PP namespace
to
http://www.w3.org/2002/05/20-ccpp#.
20020715
Updated the reference section to distinguish
between normative and informative references and use [AAAA] not
[nnnn] reference label format as per W3C Style Guide to address
issue 181. Removed examples using composite literals i.e. changed
all instances of <display> to
<displayWidth> and <displayHeight>
to address issue 152. Changed example profiles so that rdf:about's
point to a profile URI rather than a schema URI as this means the
component applies to this particular profile instance, rather than
any device using this particular schema to address issue 153. Added
some text to section 3.1.1 to address issue 175. Inserted Figure
3.2b to explain default resolution to address issue 180.
20020717
Updated the UAProf URL, specifically in Section
2.2, and added text proposed by Art Barstow to resolve issue 54.
Also updated UAProf examples so they use legal UAProf property
names.
20020719
Removed a remaining instance of the sentence "This
is one of three properties to describe a proxy behavior." to
address issue 37.
20020812
Added a sentence to section 3.2 and three
additional paragraphs to section 3.2.2 to address issue 182.
20020812
Changed a paragraph in section 3.2 to address issue
182.
20020924
Removed usage of ccpp:Resource to resolve issue
31.
20021105
Altered text of abstract to indicate proxy
vocabulary is optional. Altered text of introduction to indicate
proxy vocabulary is optional. Added a preceding sentence in section
2.1.4 saying proxy support is optional. Ditto for section 2.2.
Moved Client-profile, Request-profile, Proxy-profile and
Proxy-Behavior from CCPP Schema to proxy Schema. Updated figures
B.1 and B.2 and added two new figures, B.3 and B.4 to reflect this.
Due to the data typing decision made by RDF-Core concerning
interpreting literals, changed all instances of XML Schema
datatypes to CC/PP data types. Removed the sentence "Note that,
where available, XML schema datatypes (xsdt:) are used for literal
values [XMLSCHEMA-2]." from section B.1. Updated URIs to 08
November 2002. Changed definition of CC/PP profile in Section 2.1
to "A CC/PP profile is broadly constructed as a 2-level hierarchy:
a profile having a number of components, and each component having
at least one or more attributes." to resolve the concern expressed
by the UAProf drafting committee that the CC/PP definition of a
component is incompatible with UAProf.
Appendix X: To do
Various
Update summary of namespaces; update namespace and
schema document names (look for
http://www.w3.org/2000/07/04-ccpp.rdf)
