The explosive growth of Internet-enabled gadgets has caused a major problem: the current Web infrastructure is simply not ready for them.

The Web has (some) beautiful HTML pages that are at best ugly on microbrowsers...when they can be viewed at all. Most Web servers don't recognize these gadgets or what they can do; they don't know how to share rich, graphic content with them. Those that work rely on the gadget (or worse, its user) to memorize new Web addresses that point to specially built pages intended for viewing on that particular device. Your elaborate Web application doesn't work on the thousands of new gadgets your customers want to use to interact with you. New pages with a sliver of the original content and functionality you just finished building are required. It's actually worse than that: you need new pages for each family of devices - the phones, the pagers, the PDAs, and whatever comes next.

When configured properly, Web servers really do know how to recognize gadgets and send them appropriate data, but the gadgets often mislead Web servers about who and what they are, causing problems. Many use nonstandard (and poorly documented) data. Only very specialized, and hence limited, applications can work with these constraints. New applications need to support all manner of different client devices, from WAP browsers and RIM pagers to PDAs running Palm OS or WinCE, all with varying form factors and computational capabilities.

People have been working on this problem for about seven years. The W3C is the leader in this area. Their work products come under the name "Composite Capabilities/Preference Profiles," or CC/PP.

Out of Chaos...
So how can CC/PP help bring order to this seeming chaos? Through a standard definition called the Device Capability Profile. This profile describes the hardware, software, and even network characteristics of a device. In the simplest case the device sends its profile to a Web server, which reads the profile and uses it to choose the correct content to return (see Figure 1).

To get the most from CC/PP, you can use profiles to allow a single Web page to handle a whole family of gadgets by providing minor customizations of the page dynamically. This isn't the same as providing separate pages for every device (which is bad), nor is it the same as having a single page for all devices (which is a pipe dream).

Fewer pages, logically organized by family, are desirable due to the reduced cost to build and maintain the Web site. Profiles must be written in a language the Web server can both read and understand. The language must have a grammar that a computer can understand and a limited, well-defined vocabulary. CC/PP uses XML as the grammar for representing profiles. To be precise, profile data is described using the Resource Description Format (RDF) and encoded in XML.

The profile also needs a specific vocabulary. This is just a list of terms and what they mean in the limited context of gadget capabilities. Terms are simple, like color capable or screen size. To organize the terms and make the vocabulary easy for humans to understand, a new concept is useful - that of a profile component. A few sample components are Hardware Platform, Software Platform, Browser, Network Characteristics, and Operating System. A CC/PP vocabulary defines the recognized components, their attributes, and type information. Listing 1 provides a sample profile containing three components and many attributes (namespace identifiers ignored for clarity).

Now that we can read, write, and understand profiles, we must ensure that it stays that way. Your gadget and my Web server must use the same CC/PP vocabulary in order to communicate effectively. Since supporting a vocabulary requires custom programming, having too many is as bad as having none at all due to the incompatibilities resulting from trying to support too many things.

Figure 2 provides a more detailed example that shows the role of CC/PP in a Web page request.

CC/PP provides the simplest way to get quality information about the capabilities of a client device. A major point of using CC/PP is that the server doesn't need any advance information about gadgets or any other Web browser. You design your pages against the CC/PP vocabulary. Using CC/PP to drive page customization improves the user experience.

Now for the Bad News
Up to this point I've been talking about Web servers knowing CC/PP vocabularies and gadgets sending profiles. This is the future of CC/PP. In reality, profile information is not currently being sent as part of the request, and standard Web servers don't know anything about how to retrieve a profile; even if they could, they wouldn't know what to do with the information.

There is also the problem of matching a gadget to the correct profile. You must use the existing HTTP header data sent by all gadgets to find a suitable profile. Unfortunately, standards for header data are perhaps too liberal, and just about anything and everything shows up in HTTP headers, complicating the task. This doesn't mean that CC/PP can't be used right now - it's just not readily available, and has its challenges.

In order to realize the potential of CC/PP, manufacturers must step up and create Internet-based CC/PP repositories describing their hardware and software. Unfortunately, this will be challenging for manufacturers, since the current information they provide is inadequate, inaccurate, and hard to find...when possible at all. So where will CC/PP information come from?

W3C CC/PP Working Group Web page: www.w3.org/Mobile/CCPP

Published Jun. 20, 2002 — Reads 5,535
Copyright © 2008 SYS-CON Media. All Rights Reserved.

Related Links

▪ Figure 1

▪ Figure 2

▪ Source Code

About Erich Izdepski
Erich Izdepski is a senior developer at Cysive, Inc. based in Reston VA. Since joining Cysive in 2000, Erich has worked on several projects involving integrating J2EE and legacy applications. He is currently involved in the development of CymbioTM, Cysive’s J2EE-based Interaction Server product.