serving up device independence the extensible way

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

XML and XSL style sheets may hold the key to dealing with content production in a multi-modal landscape filled with devices of varying capabilities.
By Amy Cowen

In past years, browser issues were the source of much frustration for web authors. In light of a growing population of devices with assorted presentation capabilities, however, issues related to content functioning appropriately in various contexts and on various devices - from desktop- to phone-sized - have thundered onto the scene rendering PC-based web browser concerns a dinosaur of molehill proportions in comparison to the challenge of dealing with the vast differences present in today's devices.

The solution may lie in current work surrounding device independence. The theory: let the device identify itself and its capabilities and have the content prepared and stored in such a way as to supply an appropriate presentation for the requesting device. The fundamental principle: content has to be functional regardless of device.

The bottom line: content authors have their work cut out for them.

informed delivery

In introductory remarks to the W3C's Device Independence Principles, the authors write: "The focus of device independence is on matching Web content to the needs, capabilities and limitations of the delivery environment. We wish to minimize the extent to which Web content is authored in a way that is only deliverable on a restricted set of devices."

Despite reference to "authoring" in the line above, approaching device independence is likely to depend first upon devices being able to convey their capabilities using future CC//PP-vocabularies. The WAP Forum's UAProf specification is one such CC/PP vocabulary and allows WAP devices to communicate device information to the server.

That information would then be resolved and assembled into a cohesive "device profile" using an application like the open source Delivery Context Library or DELI developed by HPLabs Bristol.

CC/PP and UAProf-aware devices are a start, but the content itself must be stored in a manner that allows it to easily be transformed, transcoded, or otherwise smartly delivered in a format the device can handle.

As Mark Butler, creator of DELI, notes, "while CC/PP and UAProf establish a framework with which devices can provide compatibility information to servers as they make a request for information, two other huge pieces of the puzzle are 1) what does the server do with that information and 2) how is the content delivery process impacted by the availability of the device profile information."

DELI addresses the first piece of the puzzle.

With a solution like DELI in place, the device profile is assembled, retrieved, and available as the content is prepared and delivered. The server can use this information to transform existing content, e.g. to resize an image, or select an appropriate version of the content when the author has created multiple versions. By composing the page from a number of objects selected or transformed in this way, the resulting page gives the impression that it has been specially created for a device with certain qualities and capabilities.

As Roger Gimson, HPLabs Bristol researcher and member of the W3C Device Independence Activity, noted in "Four Principles for Device-Independent Publishing," the responsibility for providing content in a suitable format falls squarely within the content producer's corner. "It is up to the content provider to make sure what they deliver is suitable for the delivery device. It should not be assumed that each device, or delivery path to the device, can adapt the content," he writes.

Streamlining the content creation process so that it is practical and efficient in terms of time and complexity - but effective in terms of device-specific content negotiation and delivery - is the challenge.

an extensible approach

Using XML for content storage and XSLT to transform content appropriately is one approach to working with CC/PP and UAProf profiles. XML's focus on content allows authors to store content separate from instructions related to the formatting and display of that content. This content can then be retrieved as needed when delivered to a requesting device.

For example, if only a headline and introductory paragraph is needed for display on a mobile device, just that content can be pulled when the file is delivered - provided the content has been tagged appropriately in the XML and an XSLT style sheet is in place to handle the requesting device.

XSLT style sheets are responsible for determining what content from the XML data is delivered and in what format that content is rendered. This approach provides both flexibility and efficiency as the content itself needs to be stored only once - in the XML file. Device-specific formatting and delivery alternatives are handled through XSLT style sheets which designate "what" content to pull. These style sheets do not re-store the content. Instead, the XSLT files merely state what content should be retrieved from the XML - and how it should be handled in terms of formatting and display.

If CC/PP or UAProf profile information is available, then XSLT style sheets can be created to accommodate the various devices based on their profiles.

a rocky road

The XML/XSLT approach appears to offer a viable solution for marking up content in a manner that can be easily reused, and for storing formatting information in a manner that can be applied to various classes of devices.

Unfortunately, multiple XSLT style sheets will be required - at least one per device class, and many sites fail to use a generic enough templating structure to allow the creation of XSLT style sheets for the "site" as a whole, instead necessitating different style sheets for each page of the site.

Butler agrees that there are potential pitfalls with an XML/XSLT approach. "XSLT was originally used to transform content for devices that used different markup languages such as WML or HTML," he says. "However, often this isn't enough as even devices that claim to use the same language may vary in behaviour. For example, Nokia and Openwave browsers implement selection lists in different ways. This means you need stylesheets for individual devices, not types of device."

The Device Independent Working Group's focus on "delivery context" aims to address this problem by taking into account not just the device itself - the hardware - but also the "software, browser and network connection of the target device," says Butler.

Unfortunately, this doesn't necessarily make things easier.

"In current XSLT based solutions, in order to optimise all presentations, it is necessary to have a style sheet per page per device. One of the advantages of using device profiles is that instead of having to consider all the devices available each time you make a decision about content - the whole device space - you can just concentrate on the capabilities that are most relevant to that decision. If we can demonstrate how this can be done using XML/XSLT, then we can significantly simplify the task of making sites device independent" explains Butler.

Without these techniques, the potential number of style sheets required to support the variety of devices in usecould be staggering.

Gimson agrees that cultivating device independence won't be easy. "In the short to medium term, it will remain a labour-intensive task to construct service presentations that can be delivered to users through a variety of web devices," he notes. "Our vision here is twofold: in the short term to improve the characterisation of devices so that it is easier to match the delivery to their capabilities; in the medium term to express presentations in a more device-independent fashion."

Despite the inherent challenges in an XML/XSLT strategy for dealing with CC/PP and UAProf device profile information, Butler feels that investigating how these technologies can be used together is an important step forward.

"XSLT is just a first step," says Butler. "It's an established technology for transforming content for different target devices. In the future, phones and PCs may use common markup languages which will simplify things considerably. In addition, device independent markup languages based on XML will make authoring easier. These approaches will still need device profiles, so right now we want to answer questions like what vocabularies devices should use and how servers should process that information. Using XSLT with CC/PP will help us find these answers."

DELI delivers

In a CC/PP-based approach to device independence, DELI plays the critical role of resolving CC/PP or UAProf profile information passed along from the requesting device. Right now, however, "DELI provides no support for content selection, generation, or transformation," says Butler.

"Instead, it is proposed that DELI should be integrated with existing applications that transform content for clients based on the user agent string," he explains.

To this end, Butler and Ovidiu Predescu, HP Middleware Division R&D, have been working on integrating DELI into Apache Cocoon, an open-source XML framework that has been widely accepted in the developer community. A release of Cocoon with DELI support is scheduled for this spring.