deli-style profile resolution: approaching device independence

Originally from The m-pulse (HP e-zine on mobility)

With HP's open source DELI, content authors can take advantage of CC/PP-based device profiles to serve up the right content every time and for every device.
By Amy Cowen

As more and more users interact with web-based materials using devices other than desktop PC's, problems associated with content formatting, rendering, and delivery take a quantum leap in terms of complexity, making traditional browser compatibility and accessibility strategies appear rudimentary at best.

The same content needs to be viewable regardless of the user's chosen - or current - device... on a tiny phone screen, on a PDA, on a laptop, on a desktop, via a car browser, or on any other device the user happens to be holding, looking at, speaking to, or otherwise interacting with when requesting web-based information.

There are numerous parameters to take into account - browser, language support, OS, user preferences, screen size, color support, connection speed, graphics capabilities, audio capabilities. The list goes on, making it easy to conclude that it's acceptable to assume that not every site will work for every viewer or under all circumstances and in all contexts.

This conclusion, however, has dangerous implications for the future of web-based content given growing demand for, and use of, mobile services and devices. Companies saddled with such complacency may find themselves on the outskirts, unable to tap into the growing mobile and multi-modal audience.

a declaration of independence

Through the Device Independence Activity (DIA), the W3C is looking at "access" issues that stand to multiply exponentially in coming years.

While closely aligned with the W3C Web Accessibility Initiative and the W3C Internationalization Activity, the focus of the DIA extends beyond these groups adding support for anyhow to the equation:

"The vision we share with others is to allow the Web to be accessible by anyone, anywhere, anytime, anyhow. The focus of the W3C Web Accessibility Initiative is on making the Web accessible to anyone, including those with disabilities. The focus of the W3C Internationalization Activity is on making the Web accessible anywhere, including support for many writing systems and languages. The focus of the W3C Device Independence Activity is on making the Web accessible anytime and anyhow, in particular by supporting many access mechanisms (including mobile and personal devices, that can provide access anytime) and many modes of use (including visual and auditory ones, that can provide access anyhow)."

The Device Independence Principles working draft, released Sept. 18, 2001, stresses that addressing the problems raised by the current device dependent state of most web-based information requires collaboration between device manufacturers, service providers, and content authors and producers. Requiring the involvement and cooperation of all pieces of the hardware, production, and delivery chain makes putting device independent strategies into action a challenging proposition.

And it's unclear who will step up to the plate first.

According to Roger Gimson, HPLabs Bristol researcher and editor of the Device Independence Principles, "there is potentially a situation where neither the client side nor the server side will commit before the other to supporting exchange of device capabilities. However, the potential benefits to both parties in achieving a better user experience make it an important goal."

Central to the issue of device independence is the core belief that content should be accessible regardless of the device by which it is being accessed and on which it is being viewed. This is underscored in the following "fundamental" principle: "For some Web content or application to be device independent, it should be possible for a user to obtain a functional presentation associated with its Web page identifier via any access mechanism. It does not say that the presentation will be the same on every device. But it does say that the user should be able to obtain a presentation and that the presentation obtained should be at least functional."

			This example from the Device Independence Principles working draft highlights how the same information might take shape on differing devices. "A user enters a Web page identifier for a weather forecasting page on different devices. On the screen of a PDA, the presentation page shows the text 'Tomorrow' with a visual graphic of a sun. On the screen of a phone, the presentation page shows the text 'Tomorrow: sun.' On the speaker of an in-car PC, the presentation page speaks the words 'Tomorrow will be sunny.' These are all presentations that have been adapted to be functional for their specific access mechanisms."

This distinction between "sameness" and "functionality" is one developers and users will need to embrace in a device independent world. Files will not necessarily look identical when viewed on numerous devices and across numerous interfaces, but the content should remain usable regardless of the interface. That's different than today's approach of using barebones ALT text.

Given the number of parameters that can differ from device to device, authors clearly have their work cut out for them. However, in the face of growing numbers of devices, authors can't easily address device independence issues unless they can tell "what" capabilities a device requesting information has.

a vehicle for vocabulary

Establishing a vehicle for making this information available is the goal of the Composite Capability / Preferences Profile (CC/PP). Based on the Resource Description Framework (RDF), CC/PP provides a framework for the development of vocabularies by which devices can convey their capabilities when making a request of a server.

Servers would then be able to use the profile provided by the CC/PP-aware device to determine what content to serve.

CC/PP doesn't define a vocabulary itself, however. Instead, it is a "generic language for constructing such vocabularies," says Mark Butler, a researcher in HPLabs Bristol working on device independence solutions.

The WAP Forum's mobile phone-specific WAP User Agent Profile specification (UAProf), an application of CC/PP, is one such vocabulary and demonstrates the potential CC/PP offers. UAProf may be a step in the right direction, but Butler suggests a more desirable approach would be the creation of "a single vocabulary for all web clients rather than just WAP devices."

Similarly, Gimson notes that while "CC/PP provides a framework, and a good starting point, for conveying device capabilities from a client to a server," one of the issues the DI group will be considering in its upcoming March workshop is how to "avoid a proliferation of incompatible vocabularies for describing device capabilities."

responsible devices

Rather than providing a vocabulary, CC/PP provides a mechanism by which developers can begin establishing vocabularies devices will use to uphold one of the principles in the Device Independence Principles draft regarding the device's responsibility for characterization of delivery context: "The user agent should be able to associate the characteristics of the delivery context with a request of a particular Web page identifier."

The principles continues to suggest that "when a request is made over the Web for a presentation page, not only should the request specify the Web page identifier for the page, but also it should provide enough information about the access mechanism and the user that the right kind of presentation can be provided."

In other words, the device has to be able to express to the server what it can and can't accept - what its limitations are for content delivery and presentation as well as what special instructions the user has specified for receiving information on the device. For example, a device may be capable of rendering speech/audio, but the user may have temporarily turned off those abilities in a given context. The device needs to relay that information along with a summary of its on-board capabilities.

CC/PP is a framework for providing this information. It does not specify how the server should handle the information, however.

"CC/PP is not the complete solution," acknowledges Butler, "just a necessary part of it."

He should know.

As creator of the Delivery Context Library or DELI solution, HPLabs Bristol's Butler has been working on an application designed to support CC/PP and bridge the gap between the CC/PP-aware device and the server's delivery of device-appropriate content.

deciphering profiles

Butler defines DELI as an "open-source library that provides an application interface (API) to allow Java servlets to resolve HTTP requests containing delivery context information from CC/PP or UAProf capable devices and query the resolved profile."

Designed to sit on any server capable of processing Java servlets, DELI receives CC/PP or UAProf information from the device, resolves that information, and can then pass it along so that appropriate content transformations can take place. Central to this process is profile resolution.

As Butler explains, "one of the design aims of [CC/PP] standards was the efficient delivery of delivery context to the server even via low bandwidth wireless networks. This is achieved by the use of profile references and profile differences that work as follows: instead of sending an entire profile with every request a client only sends a reference to a profile, stored on a third device known as a profile repository, along with a list of overrides specific to this particular client. The process of interpreting the profile references and differences is known as profile resolution."

Acting as a middle-agent, DELI performs profile resolution, reassembling packets and then querying profiles in the profile repository.

In the absence of DELI, or another application able to resolve the profile, the CC/PP or UAProf information is ignored - and the server is unable to deliver a version of the content appropriate for the client's capabilities.

Profile resolution solutions that are not CC/PP and/or UAProf-aware resort to reading HTTP headers and user-agent strings, which they then match to a device database. Relying on such a solution, however, means the corresponding database has to be continually updated to remain current.

Unlike HTTP-based solutions, DELI is always up to date when it comes to CC/PP-aware devices. Because DELI reads and interprets the CC/PP profile as a request is made, it doesn't need to know anything else about the device and no database of CC/PP devices needs to be maintained.

legacy support

DELI has been designed to handle yet-to-be-created CC/PP vocabularies - not just the UAProf CC/PP derivative in use today. But, DELI is also equipped to deal with legacy devices that are not CC/PP- or UAProf-"aware," says Butler.

When DELI interprets a request from a device that is not accompanied by CC/PP or UAProf information, DELI uses the user-agent string to identify the device in a database of older devices, and then provides a "legacy profile" for that device.

According to Butler, support for older devices is one of DELI's chief advantages over other profile resolution solutions - and other CC/PP reference implementations.

DELI's legacy support "helps avoid the 'chicken and egg' situation," he says. "Browser or device manufacturers don't want to support CC/PP because servers don't support it and vice-versa. DELI allows people to start building CC/PP- or UAProf-aware web sites now, even though devices are not available. When those devices become available, these standards will ensure sites work correctly with the new devices."

looking ahead

Despite the range of devices on the market today, multi-modal web access hasn't become mainstream enough to put the industry at a critical device dependent impasse. That such an impasse lurks in the future is a reality the mobile industry - and web developers, designers, and content owners - must face.

For Gimson, hope lies in the creation and adoption of standards.

"The cost of authoring applications for many different devices will force more device independent solutions to be found. However, there is a risk that many incompatible proprietary solutions could be created for adapting applications to different devices," says Gimson.

"Now is the right moment to be introducing standards that will allow even more authors to reach even more users no matter what access devices they may use."

A future of CC/PP vocabularies, and CC/PP-descendent devices, however, depends upon CC/PP's widespread adoption by the industry - both manufacturers and content developers willing to work with CC/PP-based profiles and vocabularies. On the road to such adoption, CC/PP needs multiple reference implementations, says Butler, to be approved and re-labeled a W3C "recommendation." He hopes that DELI will be one of these implementations.

Gimson agrees that "DELI provides an essential piece of glue that allows delivery context information to be resolved and made available to server-side applications. Since it supports legacy techniques, such as the use of conventional HTTP header information, as well as CC/PP and UAProf, it enables server-side applications to be developed now that can support both the old and new approaches. In this way it smoothes the path towards adoption of the new standards."

The industry, too, is responding positively to what DELI offers. "DELI has one important advantage over commercial solutions for device profiling," says Butler. "It provides a route for migrating to CC/PP and UAProf whereas the commercial solutions do not - and this is attractive to the network operators."