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:

• Server-driven content negotiation, as defined by HTTP,
• On-the-fly content selection and presentation based on user agent detection, using scripting languages,
• HTML object and link elements have mechanisms defining alternate behaviours,
• SMIL (pronounced "smile"), the multimedia language for audio/visual content, has a switch element defining alternate elements to chose from, and can be used, for example, to choose some content based on available bandwidth,
• CSS also has such a mechanism called Media Queries for selecting appropriate style sheets.

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:

• User agent sniffing is generally considered a very bad idea. Sniffing methods are bound to become obsolete, or result in a high level of maintenance to keep up with growth and change within the user agent market.
• In the case of server-side selection, only a very limited set of information is given by the user agent to the server. This limited information is used to select the right content or behaviour. But the user agent cannot specify, for example, at which resolution it is working in order to send images and other content at a proper size, or whether the agent in question is able to handle HTML frames.
• Selection will always be limited to a finite set of choices. Even by generating a very large number of variants or defining numerous alternate behaviors, there is no way selection will provide a way to define an infinite variety of content.
• Generating content to match need is very nice for the resulting user experience, but makes Web authoring a very tedious task.

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.

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:

• Resizing images to fit the device's resolution. This can be done automatically by proxies based on the resolution information given by the CC/PP profile. And of course, with SVG it is even easier.
• XHTML is powerful because it is XML, or so we've been taught. And the power of XML is often demonstrated through the use of XSLT, the transformation language for XML. Combining the possibility to transform XHTML content through XSLT with the flexibility and accuracy provided by CC/PP makes it possible to transform hypertext content on-the-fly beyond what style sheets already allow. You can show tabular content in a linear fashion for agents that can't handle tables, transform a long XHTML document with many sections in an SVG slideshow and so on, with very few limitations.
• The Open Mobile Alliance (OMA) already implements CC/PP in their UAProf technology for WAP devices. This technology is used to help proxies transform content for mobile use.

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

• CC/PP Home page at W3C
• content negotiation defined in the HTTP specification
• CSS Media Queries and how they relate to CC/PP
• SMIL's SWITCH element

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