Composite Capability/Preference Profiles (CC/PP): Structure
W3C Working Draft 21 July 2000
- This Version:
- http://www.w3.org/TR/2000/WD-CCPP-struct-20000721/
- Latest Version:
- http://www.w3.org/TR/CCPP-struct/
- Editors
- Franklin Reynolds, franklin.reynolds@research.nokia.com,
Nokia Research Center
- Chris Woodrow, woodroc@metaphoria.net,
Information Architects
- Hidetaka Ohto, ohto@w3.org, W3C/Panasonic
Copyright ©
2000 W3C ® (MIT, INRIA, Keio), All
Rights Reserved. W3C liability,
trademark,
document
use and software
licensing rules apply.
Abstract
In this document we describe a method for using RDF, the Resource
Description Framework of the W3C, to create a general, yet extensible
framework for describing user preferences and device capabilities. This
information can be collected into a profile and provided by user agents to
servers and content providers. The user's preferences and the capabilities of
the user's agents can be used to customize a service or content provided by a
service.
Status of this document
This document is a working draft made available by the World Wide Web
Consortium (W3C) for discussion only. This indicates no endorsement of its
content. This is the first public working draft, and work in progress,
representing the current consensus of the working group, and future updates
and changes are likely.
The working group is part of the W3C Mobile Access activity.
Continued status of the work is reported on the CC/PP Working Group Home Page (Member-only link).
It incorporates suggestions resulting from reviews and active participation
by members of the IETF CONNEG working group and the WAP Forum UAprof drafting
committee.
Please send comments and feedback to www-mobile@w3.org.
A list of current W3C Recommendations and other technical documents can be
found at http://www.w3.org/TR/.
All RDF codes in this document have been validated with SiRPAC and W3C perl RDF browser, the W3C
RDF validator/visualizer.
Table of Contents
Terminology and Abbreviations
1. Introduction
1.1 Executive Summary of Requirements
2. Composite Capability/Preferences Profiles (CC/PP)
2.1 Namespaces
2.2 Defaults
2.3 Proxy Support
3. CC/PP Framework Schema
4. Acknowledgments
5. References
Appendix: Unresolved issues
The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," "MAY," and "MAY
NOT" in this document are to be interpreted as described in RFC 2119 [RFC2119].
All terminology and abbreviations used in this document are defined in the
[CCPP-ta].
As the number and sophistication of applications and devices used to access
the Web grows, there has been a corresponding increase in pressure for
application developers to tailor the content or service provide to desires or
capabilities of individual users. The current mechanisms, including accept
headers and <alt> tags, are somewhat awkward and limited. What is needed is
a general purpose, extensible user profile service that can be used to
describe the preferences of the user and the capabilities of the user's
computing platform. Some of the information contained in such a profile may be
sensitive, consequently the profile service should provide adequate trust
mechanisms deal with privacy concerns.
In this document we describe a framework for Composite Capability /
Preference Profiles (CC/PP). It is derived from earlier work done within the
W3C Mobile Access Interest Group [CCPPNote] and the
WAP Forum's User Agent Profile working group [UAProf].
The CC/PP framework is intended to provide general purpose, extensible and
interoperable user agent profiles. In this document we will emphasize the use
of CC/PP in the context of the Web, but we expect that the framework and the
profiles may have wide-spread applicability. User agents include the hardware
and software components utilized by the user to access the Web. The profiles
containing user agent capabilities and preferences can be thought of as
metadata or properties and descriptions of the significant user agent hardware
and software applications. The framework provides the means to package user
agent profile information in an interoperable format, but it does not specify
a communications protocol. CC/PP is intended to be protocol independent,
though special care has been taken to consider the use of HTTP. An
implementation guidelines document will be written which discusses CC/PP
issues related to HTTP.
The CC/PP framework is based on XML/RDF. RDF, the Resource Description
Framework, was designed by the W3C consortium as a general purpose metadata
description language. XML/RDF provides the framework with the basic tools for
both vocabulary extensibility, via XML namespaces, and interoperability. There
is a specification that describes how to encode RDF using XML [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 framework since user agent profiles are
metadata intended primarily for communication between user agents and
servers.
Alternate methods for describing the attributes or metadata of documents
are under investigation by other organizations such as the IETF Content
Negotiation [CONNEG] working group. Though the CONNEG
and CC/PP frameworks are not directly compatible, efforts are underway to
define interoperable vocabularies [CCPP-vocab]. The
CONNEG working group has also developed a media feature matching algebra.
Efforts are underway to insure that the CONNEG algebra and RDF are
complementary technologies. In addition to the IETF we are particularly
concerned about collaboration with the WAP Forum and ETSI.
The goal of this work is to create an extensible, general purpose framework
for the interoperable encoding of user agent profiles. Though these profiles
are intended to have a wide range of applicability, they must be suitable for
content negotiation between user agents and HTTP-based servers. The framework
will be based on the original CC/PP work described in the W3C CC/PP Note [CCPPNote]. The framework must be extensible. It must be
possible to add new capabilities to existing vocabularies, new vocabularies
and support for new user agents. Profiles will be encoded using XML/RDF and
the XML namespaces and RDF schemas will be used to describe capability
vocabularies.
The encoding of the profiles is intended to be independent of any
particular transport, but the use by HTTP MUST be supported. Since profiles
may be quite verbose, means to reduce the overhead for low bandwidth networks,
such as the cell phone network, must be considered. It MUST be possible to
assemble a profile from information provided from multiple sources. Caches,
proxies and gateways must be supported[CCPPEx].
It must be possible to provide the authentication of the source of the
profile, confidentiality of the information in a profile and the integrity of
the data in a profile. It should be possible to limit the information
distributed in a profile to only that information necessary to provide the
desired service. It should be possible to achieve these trust goals without
relying on transport related security services.
For more information regarding the requirements for this work, see [CCPP-ra].
The basic data model for a CC/PP is a tree. The initial branches are the
components or user agents described in the profile. Each major component may
have a collection of attributes or preferences. Examples of major components
are the hardware platform upon which all the software is executing, the
software platform upon which all the applications are hosted and each
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 look like this:
fig.1
[Profile]----component--->[TerminalHardware]
|
--------component--->[TerminalSoftware]
|
--------component--->[TerminalBrowser]
|
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,
it is unlikely that this flexibility will be used in the creation of complex
data models for profiles. A capability can often be described with a single
RDF statement with a simple, atomic value. In situations where this is not
sufficient, RDF makes capabilities with complex, structured values possible.
This can be useful when multiple values are needed. For example, a browser may
support multiple versions of HTML. Figure 2 illustrates this tree structure
with a few components and properties. Each component has a type from which its
class definition is inherited.
fig.2
[MyProfile]--component-->[TerminalHardware]---type--->HardwarePlatform
| |
| ------CPU------>"PPC"
| |
| ---ScreenSize-->"320x200"
|
|
----component-->[TerminalSoftware]---type--->SoftwarePlatform
| |
| ---OSName----->"EPOC"
| |
| ---OSVersion-->"2.0"
| |
| ---OSVendor--->"Symbian"
|
|
----component-->[Browser]---type--->BrowserUA
|
----BrowserName------>"Mozilla"
|
----BrowserVersion--->"5.0"
|
----CcppAccept------->[ ]--type-->Bag
|
---li--->"text/plain"
|
---li--->"text/vnd.wap.wml"
|
RDF supports multiple namespaces for properties. CC/PP uses this to
separate the vocabulary associated with the framework from vocabularies
associated with applications. The property "component" belongs to the CC/PP
vocabulary and the the other properties belong to other vocabularies. The
graph in figure 2 can be described in RDF in a relatively straightforward
fashion. The RDF for the graph in figure 2 is follows:
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
<Description about="http://www.example.com/MyProfile">
<ccpp:component>
<Description about="http://www.example.com/TerminalHardware">
<type resource="http://www.example.com/Schema#HardwarePlatform" />
<uaprof:CPU>PPC</uaprof:CPU>
<uaprof:ScreenSize>320x200</uaprof:ScreenSize>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/TerminalSoftware">
<type resource="http://www.example.com/Schema#SoftwarePlatform" />
<uaprof:OSName>EPOC</uaprof:OSName>
<uaprof:OSVersion>2.0</uaprof:OSVersion>
<uaprof:OSVendor>Symbian</uaprof:OSVendor>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/Browser">
<type resource="http://www.example.com/Schema#BrowserUA" />
<uaprof:BrowserName>Mozilla</uaprof:BrowserName>
<uaprof:BrowserVersion>5.0</uaprof:BrowserVersion>
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp:component>
</Description>
</RDF>
|
NOTE:RDF allows resources to be identified using 'ID' or 'about'
attributes of the corresponding "Description" element. We use the 'about' form
because that allows the identifier to be expressed without reference to the
URI of the containing document. Non-local identification of a CC/PP profile is
required to support chaining to describe proxy behaviors (see section 2.3). This usage may be relaxed in a future draft as
and when some issues of naming a CC/PP profile document have been resolved.
See also: http://lists.w3.org/Archives/Public/www-rdf-comments/2000AprJun/0014.html
NOTE: The components in the profile are instances of the
components identified in the schema. They MUST be identified as such, by means
of the "type" attribute whose value matches the name of the component type in
the schema.
NOTE: The use of the RDF collection "Bag" to associate multiple
values to the property(e.g. "htmlVersionsSupported".) The use of RDF
collections, such as Bag, Alt, Seq result in anonymous nodes in a graph. The
properties of an RDF collection are always a type of LIST("li").
The CC/PP framework takes advantage of the XML
namespace mechanism. Consider the namespace declarations from the preceding
example:
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:ccpp-proxy="http://www.w3.org/2000/07/04-ccpp-proxy#"
xmlns:ccpp-client="http://www.w3.org/2000/07/04-ccpp-client#"
xmlns:uaprof=""http://www.wapforum.org/UAPROF/ccppschema-19991014#">
|
The first two namespace declarations are for RDF usage. The third
declaration names CC/PP core attribute vocabularies and classes. This
vocabulary includes "component", "Defaults" and other properties that are
intrinsic to the framework. The complete specification of this vocabulary is
included in Appendix A in the CC/PP Attribute Vocabularies document [CCPP-vocab]. The fourth and fifth namespace declaration
name proxy vocabulary, and client vocabulary for print and display. The CC/PP
attribute vocabularies document[CCPP-vocab] includes
definition of those vocabularies. Those are not mandatory parts of the core
CC/PP framework, but defined for use by CC/PP aware applications that may need
to describe certain common features. The sixth namespace declaration names
application domain specific vocabulary. In this spec, vocabulary defined by
the UAProf group in the WAP Forum is used as an example. Different user
communities and application domains (WAP Forum/UAProf, ETSI/MExE, IETF/CONNEG,
etc.) may define their own property vocabularies. The namespace is an
important mechanism for providing support for the needs of those
communities.
Each component may provide a separate, subordinate collection of default
capabilities. This collection of Defaults can either be a separate RDF
document that is named via a URI or the collection can be explicitly listed in
the profile. If a capability described in the collection of Defaults is also
described as a non-default capability, the non-default description is used.
For example, a hardware vendor may provide default profiles describing the
physical properties of each model of their products. However, the current
owner of the product may be able to add options, such as additional memory or
persistent storage or additional I/O devices that add new capabilities or
change the values of some original capabilities.
This use of an externally referenced graph which is used to describe
default properties 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 link connected to the client
is slow and expensive.
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 inline Defaults is
logically equivalent to a profile with the same non-Default data and an
externally referenced Defaults documents. The following is a simple profile
using inline Defaults and the resulting graph.
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
<Description about="http://www.example.com/MyProfile">
<ccpp:component>
<Description about="http://www.example.com/TerminalHardware">
<type resource="http://www.example.com/Schema#HardwarePlatform" />
<ccpp:Defaults>
<Description>
<type resource="http://www.example.com/Schema#HardwarePlatform" />
<uaprof:CPU>PPC</uaprof:CPU>
<uaprof:ScreenSize>320x200</uaprof:ScreenSize>
</Description>
</ccpp:Defaults>
<uaprof:ScreenSize>640x400</uaprof:ScreenSize>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/TerminalSoftware">
<type resource="http://www.example.com/Schema#SoftwarePlatform" />
<ccpp:Defaults>
<Description>
<type resource="http://www.example.com/Schema#SoftwarePlatform" />
<uaprof:OSName>EPOC</uaprof:OSName>
<uaprof:OSVersion>2.0</uaprof:OSVersion>
<uaprof:OSVendor>Symbian</uaprof:OSVendor>
</Description>
</ccpp:Defaults>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/Browser">
<type resource="http://www.example.com/Schema#BrowserUA" />
<ccpp:Defaults>
<Description>
<type resource="http://www.example.com/Schema#BrowserUA" />
<uaprof:BrowserName>Mozilla</uaprof:BrowserName>
<uaprof:BrowserVersion>5.0</uaprof:BrowserVersion>
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp:Defaults>
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
<li>text/html</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp:component>
</Description>
</RDF>
|
This CC/PP profile produces the following graph:
fig.3
[MyProfile]--component->[TerminalHardware]--type-->HardwarePlatform
| |
| ----Defaults-->[ ]--type-->HardwarePlatform
| | |
| | -----CPU----->"PPC"
| | |
| | --ScreenSize->"320x200"
| |
| --ScreenSize-->"640x400"
|
-----component-->[TerminalSoftware]--type-->SoftwarePlatform
| |
| --Defaults-->[ ]--type-->SoftwarePlatform
| |
| ---OSName----->"EPOC"
| |
| ---OSVersion-->"2.0"
| |
| ---OSVendor--->"Symbian"
|
--component-->[TerminalBrowser]--type-->BrowserUA
|
----Defaults-->[ ]--type-->BrowserUA
| |
| --BrowserName---->"Mozilla"
| |
| --BrowserVersion-->"5.0"
| |
| ---CcppAccept->[ ]--type-->Bag
| |
| --li-->"text/plain"
| |
| --li-->"text/vnd.wap.wml"
|
----CcppAccept-->[ ]--type-->Bag
|
--li-->"text/plain"
|
--li-->"text/vnd.wap.wml"
|
--li-->"text/html"
|
Inline Defaults are logically equivalent to externally referenced Defaults.
Inline Defaults may be used if a client prefers not to release some of the
information provided by the Defaults document or it may be used if the
Defaults document is unavailable. The following is the external Default
version of the same profile.
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
<Description about="http://www.example.com/MyProfile">
<ccpp:component>
<Description about="http://www.example.com/TerminalHardware">
<type resource="http://www.example.com/Schema#HardwarePlatform" />
<ccpp:Defaults rdf:resource="http://www.nokia.com/profiles/2000k" />
<uaprof:ScreenSize>640x400</uaprof:ScreenSize>
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/TerminalSoftware">
<type resource="http://www.example.com/Schema#SoftwarePlatform" />
<ccpp:Defaults rdf:resource="http://www.Symbian.com/profiles/EPOC" />
</Description>
</ccpp:component>
<ccpp:component>
<Description about="http://www.example.com/Browser">
<type resource="http://www.example.com/Schema#BrowserUA" />
<ccpp:Defaults rdf:resource="http://www.nokia.com/profiles/Mozilla" />
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
<li>text/html</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp:component>
</Description>
</RDF>
|
Each external Defaults document is a separate RDF document referenced by a
URI. This simplifies the task of parsing and combining externally referenced
Defaults into a form that is equivalent to the inline form.
NOTE: The Defaults document uses "Description" statement as the
root node. The Description is named using "about" whose value is a URI. The
URI MUST correspond to the value in the "rdf:resource" attribute in the
"Defaults" element in the source document. In the examples of Defaults
documents below, the URLs for external Defaults documents are used. However
the each URI does not have to be a URL as long as the URI is uniquely
identified, and the corresponding URI is used in both of source document and
external Defaults document.
The examples of Defaults documents are as follows:
http://www.nokia.com/profiles/2000k
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
<Description about="http://www.nokia.com/profiles/2000k">
<type resource="http://www.example.com/Schema#HardwarePlatform" />
<uaprof:CPU>PPC</uaprof:CPU>
<uaprof:ScreenSize>320x200</uaprof:ScreenSize>
</Description>
</RDF>
|
http://www.Symbian.com/profiles/EPOC
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
<Description about="http://www.Symbian.com/profiles/EPOC">
<type resource="http://www.example.com/Schema#SoftwarePlatform" />
<uaprof:OSName>EPOC</uaprof:OSName>
<uaprof:OSVersion>2.0</uaprof:OSVersion>
<uaprof:OSVendor>Symbian</uaprof:OSVendor>
</Description>
</RDF>
|
http://www.nokia.com/profiles/Mozilla
<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:uaprof="http://www.wapforum.org/UAPROF/ccppschema-19991014#">
<Description about="http://www.nokia.com/profiles/Mozilla">
<type resource="http://www.example.com/Schema#BrowserUA" />
<uaprof:BrowserName>Mozilla</uaprof:BrowserName>
<uaprof:BrowserVersion>Symbian</uaprof:BrowserVersion>
<uaprof:CcppAccept>
<Bag>
<li>text/plain</li>
<li>text/vnd.wap.wml</li>
<li>text/html</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</RDF>
|
It may be that an intervening network element, such as a transcoding proxy,
has a capability 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 (in this case, provision means to enable the service or
disable it for each client) is beyond the scope of this work. But assuming
such a proxy based capability is available, CC/PP provides the means for a
proxy to create its own profile to communicate its capabilities to a origin
server.
Figure 4 shows a sample proxy profile. The proxy profile advertises its
transcoding capability as a property of the "proxyBehaviour". Structurally, a
proxy profile mirrors the structure of a client profile, in terms of the
components to which proxy behaviours apply. The proxy vocabularies such as
"applicability", "proxyAllow" are not a mandatory part of the CC/PP
specification but is defined here for use by CC/PP aware applications that may
need to deal with proxies that play an active role in content handling(See [CCPP-vocab].) Designers of CC/PP applications that need
to deal with proxy behaviours may define their own schemas to describe the
characteristics of their proxy but they are encouraged to use the vocabulary
in [CCPP-vocab] rather than define new structures. In
this example, the proxy profile includes a browser capability component. The
proxy profile may include hardware and operating system components as well but
,in practice, it is unlikely that there is any advantage for the proxy to
advertise what sort of operating system it is using.
fig.4
[MyProxyProfile]---type--->Proxy-profile
|
--proxyBehaviour-->[ ]---type--->Proxy-behaviour
|
--applicability-->[ ]--type-->BrowserUA
| |
| --CcppAccept-->[ ]--type-->Bag
| |
| --li-->"text/vnd.wap.wml"
|
----proxyAllow--->[ ]--type-->BrowserUA
|
--CcppAccept-->[ ]--type-->Bag
|
--li-->"text/plain"
|
--li-->"text/html"
|
The CC/PP profile for the graph is follows:
<RDF xmlns='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdfs='http://www.w3.org/2000/01/rdf-schema#'
xmlns:ccpp='http://www.w3.org/2000/07/04-ccpp#'
xmlns:ccpp-proxy='http://www.w3.org/2000/07/04-ccpp-proxy#'
xmlns:uaprof='http://www.wapforum.org/UAPROF/ccppschema-19991014#'>
<Description about='http://www.example.com/MyProxyProfile'>
<type resource="http://www.w3.org/2000/07/04-ccpp-proxy#Proxy-profile" />
<ccpp-proxy:proxyBehaviour>
<Description>
<type resource="http://www.w3.org/2000/07/04-ccpp-proxy#Proxy-behaviour" />
<ccpp-proxy:applicability>
<Description>
<type resource="http://www.example.com/Schema#BrowserUA" />
<uaprof:CcppAccept>
<Bag>
<li>text/vnd.wap.wml</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp-proxy:applicability>
<ccpp-proxy:proxyAllow>
<Description>
<type resource="http://www.example.com/Schema#BrowserUA" />
<uaprof:CcppAccept>
<Bag>
<li>text/html</li>
<li>text/plain</li>
</Bag>
</uaprof:CcppAccept>
</Description>
</ccpp-proxy:proxyAllow>
</Description>
</ccpp-proxy:proxyBehaviour>
</Description>
</RDF>
|
A proxy's role as a content modifying component between client and server
is represented by chaining a description of the proxy's behaviour to the
downstream client or proxy. For any given request containing a CC/PP profile,
a new profile is dynamicaly created that refers to a CC/PP profile of the
proxy, and to the CC/PP capability in the request received by the proxy. For
the purpose, "proxyProfile" and "nextProfile" property are introduced.
For example, the user agent profile in section2.2 can be associated with
the proxy profile in this section as follows.
fig.5
[MyRequestProfile]--type-->Request-profile
|
---proxyProfile--->[MyProxyProfile]
|
---nextProfile---->[MyProfile]
|
The CC/PP profile for the graph is follows:
<RDF
xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:ccpp="http://www.w3.org/2000/07/04-ccpp#"
xmlns:ccpp-proxy="http://www.w3.org/2000/07/04-ccpp-proxy#">
<Description about="http://www.example.com/MyRequestProfile">
<type resource="http://www.w3.org/2000/07/04-ccpp-proxy#Request-profile" />
<ccpp-proxy:proxyProfile rdf:resource="http://www.example.com/MyProxyProfile" />
<ccpp-proxy:nextProfile rdf:resource="http://www.example.com/MyProfile" />
</Description>
</RDF>
|
There may be multiple intervening network hosts, each of which, needs to be
able to advertise some capability. In some cases, the order in which these
network hosts are encountered is important. For example, a firewall that
filters some types of content and a transcoding proxy that converts the unsafe
content to a safe form of content. If the proxy is behind the firewall then
the origin server is wasting its time if it sends any of the content that the
firewall is going to discard. If the proxy is in front of the firewall, then
the origin server may reasonably expect the proxy to convert the content to a
safe form that will pass through the firewall. To indicate order of occurance,
profiles can use the "proxyProfile" and "nextProfile" property. Proxies that
are closer to an origin server, precede proxies that are closer to the client.
The client profile does not precede any other profile. The first proxy profile
precedes the client profile. The second proxy profile precedes the first proxy
profile, etc. (More details, see Section4. "Proxy vocabulary" in "CC/PP
Attribute Vocabularies" specification[CCPP-vocab].)
This Schema is limited to definitions used by the framework. Additional
vocabularies are necessary to define component capabilities and client
preferences (More detail, see "CC/PP Attribute Vocabularies" specification[CCPP-vocab].)
<?xml version='1.0'?>
<rdf:RDF
xmlns:rdf = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:rdfs = 'http://www.w3.org/2000/01/rdf-schema#'
xmlns:ccpp = 'http://www.w3.org/2000/07/04-ccpp#'>
<!-- CC/PP class definitions -->
<rdfs:Class rdf:ID='Resource'>
<rdfs:label>CC/PP Resource</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/01/rdf-schema#Resource'/>
<rdfs:comment>
This is a common base class for all resources whose properties
may be asserted in a CC/PP profile. (Note that the values of
CC/PP attributes are not necessarily instances of this class.)
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Profile'>
<rdfs:label>CC/PP Profile</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Resource'/>
<rdfs:comment>
This class is any complete profile that can be delivered to an
origin server or other system that generates content for a client.
May be a Request-profile or a Client-profile.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Client-profile'>
<rdfs:label>CC/PP Client profile</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Profile'/>
<rdfs:comment>
A subclass of ccpp:Profile that represents a client profile,
without any intervening proxy behaviours included. For systems
that do not have to deal with proxy behaviours (e.g. transcoding,
etc.) this is the only profile class that needs to be instantiated.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Request-profile'>
<rdfs:label>CC/PP Request profile</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Profile'/>
<rdfs:comment>
A subclass of ccpp:Profile that represents a profile created from
a client profile and one or more Proxy-profiles. This is used to
add proxy behaviour descriptions to a "downstream" request profile.
See properties ccpp:proxy-profile' and 'ccpp:next-profile'.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Proxy-profile'>
<rdfs:label>CC/PP Proxy profile</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Resource'/>
<rdfs:comment>
A complete description of a proxy's behaviour, such as a
transcoding proxy that affects the range of content that may be
generated to satisfy a request. A ccpp:Request-profile is used
to attach a proxy profile to a "downstream" client profile or
request profile.
A proxy profile has an arbitrary number of ccpp:proxy-behaviour
properties, each of which indicates an individual
ccpp:Proxy-behaviour value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Proxy-behaviour'>
<rdfs:label>CC/PP Proxy behaviour</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Resource'/>
<rdfs:comment>
A description of a single aspect of proxy behaviour. A proxy
profile is made up from an arbitrary number of these individual
proxy behaviours.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Component'>
<rdfs:label>CC/PP profile component</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Resource'/>
<rdfs:comment>
A base class for any collection of CC/PP attribute values.
A CC/PP client profile consists of one or more components,
typically using a derived class that indicates the use of the
component (e.g. uaprof:HardwarePlatform, uaprof:SoftwarePlatform).
This class is also used for collecting CC/PP attributes that
form part of a proxy behaviour description.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='URI'>
<rdfs:label>URI value</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/01/rdf-schema#Literal'/>
<rdfs:comment>
This class is used to represent any CC/PP attribute value that
is a URI identifying an arbitrary resource. When this type is
used, the value of the CC/PP attribute is the URI rather than the
resource identified by the URI.
Note that this is a superclass of ccpp:Value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Text'>
<rdfs:label>Text value</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/01/rdf-schema#Literal'/>
<rdfs:comment>
This class is used to represent any CC/PP attribute value that
is arbitrary text.
Note that this is a superclass of ccpp:Value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Integer'>
<rdfs:label>Integer value</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/01/rdf-schema#Literal'/>
<rdfs:comment>
This class is used to represent any CC/PP attribute value that
is an integer number.
Note that this is a superclass of ccpp:Value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Rational'>
<rdfs:label>Rational value</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/01/rdf-schema#Literal'/>
<rdfs:comment>
This class is used to represent any CC/PP attribute value that is
a rational number.
Note that this is a superclass of ccpp:Value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Set'>
<rdfs:label>Set value</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag'/>
<rdfs:comment>
This class is used to represent any CC/PP attribute value that
is a set of simple values. From an RDF perspective, it is
identical to an rdf:Bag, except that no element value may be
repeated.
Note that this is a superclass of ccpp:Value.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Value'>
<rdfs:label>CC/PP attribute value</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#URI'/>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Text'/>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Integer'/>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Rational'/>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Set'/>
<rdfs:comment>
This class is used to represent any value that can be the object
of a CC/PP attribute; i.e. a client feature or preference.
This schema defines various literal and set values for CC/PP
attributes. New applications requiring more complex values may
define additional rdfs:subClass arcs.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Property'>
<rdfs:label>CC/PP Property</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/1999/02/22-rdf-syntax-ns#Property'/>
<rdfs:comment>
All property arcs that constitute parts of a CC/PP profile are
defined as subclasses of ccpp:Property. This allows that in a
schema-validating environment with language missing, the CC/PP
elements of an RDF graph rooted in some given resource can be
isolated from other attributes of that resource.
</rdfs:comment>
</rdfs:Class>
<rdfs:Class rdf:ID='Attribute'>
<rdfs:label>CC/PP Attribute</rdfs:label>
<rdfs:subClassOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#Property'/>
<rdfs:comment>
All property arcs that represent client capabilities or
preferences in a CC/PP profile are deckared as subclasses of
ccpp:Attribute. This allows that structural combining elements
of a profile can be distinguished from client features in a
schema-validating environment.
</rdfs:comment>
</rdfs:Class>
<!-- CC/PP structural property definitions -->
<!-- Basic client profile description -->
<rdfs:Property rdf:ID='component'>
<rdfs:label>CC/PP component property</rdfs:label>
<rdfs:domain rdf:resource='http://www.w3.org/2000/07/04-ccpp#Client-profile'/>
<rdfs:range rdf:resource='http://www.w3.org/2000/07/04-ccpp#Component'/>
<rdfs:comment>
Indicates a component of a top-level client profile.
</rdfs:comment>
</rdfs:Property>
<rdfs:Property rdf:ID='defaults'>
<rdfs:label>CC/PP default properties</rdfs:label>
<rdfs:domain rdf:resource='http://www.w3.org/2000/07/04-ccpp#Component'/>
<rdfs:range rdf:resource='http://www.w3.org/2000/07/04-ccpp#Component'/>
<rdfs:comment>
This property indicates a Component that contains default
properties for some other component. That is, any attributes
that are not found in the subject resource but are present in
the object resource may be incorporated from the object into
the resulting CC/PP profile.
</rdfs:comment>
</rdfs:Property>
<rdfs:Property rdf:ID='Defaults'>
<rdfs:label>CC/PP default properties</rdfs:label>
<rdfs:subPropertyOf rdf:resource='http://www.w3.org/2000/07/04-ccpp#defaults'/>
<rdfs:domain rdf:resource='http://www.w3.org/2000/07/04-ccpp#Component'/>
<rdfs:range rdf:resource='http://www.w3.org/2000/07/04-ccpp#Component'/>
<rdfs:comment>
Same as 'defaults'.
Defined as sub-property for backwards compatibility with UAPROF
</rdfs:comment>
</rdfs:Property>
</rdf:RDF>
|
This specification is the work of the W3C CC/PP Working Group. This Working
Group has been chaired by Johan Helm who has been the shepherd of this work
since the idea was first proposed during the first Mobile Access Interest
Group meeting.
The editors would also like to thank the members of the working group who
contributed their valuable time to help create this document.
[CCPP-ra] Composite Capabilities/Preference
Profiles: Requirements and Architecture, W3C Working Draft
[CCPP-ta] Composite Capabilities/Preferences
Profiles: Terminology and Abbreviations
[CCPP-vocab] CC/PP Attribute Vocabularies, W3C
Working Draft
[CCPPNote] Composite Capabilities/Preferences
Profiles, W3C Note
[CCPPEx] CC/PP exchange protocol based on
HTTP Extension Framework, W3C Note
[UAProf] WAP
User Agent Profile Specification, WAP Forum Approved Specification
[CONNEG] IETF working
group on content negotiation
[RFC2119] RFC 2119
: Key words for use in RFCs to Indicate Requirement Levels
[RFC2045] Multipurpose
Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies
[RDF] Resource Description Framework,
(RDF) Model and Syntax Specification. W3C Recommendation.
[RDFSchema] Resource Description Framework (RDF)
Schema Specification. W3C Candidate Recommendation.
[Agentattrib] Client-Specific Web Services
by Using User Agent Attributes. W3C Note.
[XML] Extensible Markup Language
(XML) 1.0
Appendix : Unresolved issues
RDF subset syntax for CC/PP
currently, CC/PP syntax allows to use all RDF syntax defined in RDF Model
and Syntax specification. However the usage for some of the RDF syntax is
unclear in CC/PP contexts such as for reifications(e.g. bagID, aboutEach
etc.) We plan to define RDF subset syntax for CC/PP for easy to
use/understand/implement. The syntax would be either normative or
informative.
compatibilities w/ UAProf
CC/PP WG members agreed on maintaining backward compatibilities as much as
possible with UAProf specification defined by WAP Forum. The UAProf
specification is based on W3C Notes([CCPPNote] and
[CCPPEx].) Basically it should be possible to
maintain the compatibility since both of the CC/PP and UAProf have the
same origin. However we need more study in details.
