WaSP Asks the W3C

Introduction to Composite Capabilities / Preferences Profile (CC/PP)

The work we do on the Web today is reaching to devices far beyond the conventional computer. A range of technologies is emerging in an effort to solve problems related to delivering content to a growing number of devices. One such technology that has been under study and development for some years is Composite Capabilities/Preferences Profile or CC/PP for short. This month, WaSP asks the W3C to explain more about CC/PP and how it relates to Web designers and developers.

WaSP Asks

What is CC/PP?

The W3C Responds

CC/PP stands for Composite Capabilities/Preferences Profile, and is a system for expressing device capabilities and user preferences.

With CC/PP, a user with a specific preference, or disability-related need can clarify that even though their browser handles millions of colours, they personally can only distinguish certain colours. Or, perhaps the user navigates exclusively with a keyboard or stylus.

That's what CC/PP is, but the larger question is: Why do we need CC/PP?

With the growing popularity of ubiquitous Web devices spread across such a broad range of media and bandwidth, authoring for the Web can sometimes look like a very difficult equation to solve: how can a Web author provide cool multimedia Web content, while keeping that content small and simple enough for very basic devices?

Managing multiple devices is not a new problem, and even though the rapid growth of Web appliances beyond the familiar Web browser makes the challenge especially acute, a few solutions have been developed over the years.

Most of these solutions are based on content selection: the content is given in several equivalent variants, or has mechanisms to define alternative behaviour. Then, at the time the resource is served, either the server chooses which variant is most suitable, or the user agent decides what to do with the choices it is given.

This is easily achieved because user agents identify themselves to servers and scripting languages, and through specific features included in Web document languages:

Shortcomings of current methods

Even today, a combination of the methods detailed above can be used to serve content on a large range of devices with very good results. It remains, however, difficult to reach a perfect result:

Why CC/PP is Better

When expressing device capabilities, the strength of CC/PP is that it has the flexibility HTTP content negotiation lacks. Far from simply defining a fixed set of preferences that would be used to build device profiles, the RDF-based framework also allows the creation of whole vocabularies, making the expression of device and agent capability, as well as user preference, infinitely extensible.

Using CC/PP, creators of Web devices and user agents can easily define precise profiles for their products. Web servers and proxies can use these profiles to adapt, through fine-tuned content selection or transformation, the content they serve to the needs of the Web device.

The following graph provides an example of how CC/PP can be used to describe user preference and agent capability.

graph of ccpp

You can also view the graph in SVG, at the W3C QA site.

It may look like CC/PP does not address the issue of having to create multiple instances of Web content. In fact, it seems even worse now than with the simple HTTP negotiation. Because profiles are much more flexible and precise about what the agent can do and wants, one could think that CC/PP encourages the creation of one variant of content for each type of user agent.

CC/PP Implementations, or how I learned to stop worrying and love XHTML

CC/PP itself does not define what behaviour should follow the exchange of a CC/PP profile. And while content selection, just as in the HTTP negotiation, is one option, there is another, much more interesting perspective. CC/PP profiles could automatically trigger content transformation, allowing one source to be adapted to a broad range of devices and user agents.

The transformation mechanisms are not formally defined, but many have been envisioned or implemented already, such as:

It is of course unreasonable to think that CC/PP alone will bring the promises of a Web that will be magically easy to author for any device. Servers may not be able to handle the necessary level of computation, and even if they do, there are cases, such as P2P networks, where there are no servers at all. Still, server-side transformation of content triggered by CC/PP is an exciting development.

What the future holds

The future is more likely to see the cooperation between existing methods and languages such as SMIL's switch and CSS media queries as well as with emerging methods and languages. All of these refined and orchestrated through the use of CC/PP profiles and preferences.

The work on a device independent Web is not over yet. The protocols defining how profiles are exchanged, requested, or deduced by and between Web servers, proxies and agents are yet to be fully standardized, and so are the mechanisms regulating selection and transformation of content once a profile is set.

But CC/PP already is a major brick in building this Web. Having gone through the standardization process at W3C, CC/PP is a mature, well implemented technology that has proven its usefulness and potential. It will be implemented by Web developers to achieve device-independence for years to come.

References

Discussion

For clarification and discussion on this topic, please address your comments and questions to the W3C Web Standards Education list.

To subscribe to the list, send an email to [email protected] with “Subject: subscribe”. You can read archived posts at http://lists.w3.org/Archives/Public/public-evangelist/.