2.1 The need for Device Descriptions
Development of applications, content, and web-based services for mobile devices is more challenging than development for desktop devices. This is because they come in a much wider range of shapes, sizes and capabilities, and because they have a much wider range of browser implementations. All of these factors can affect the way in which the application behaves, quite possibly as an impact to what the developer intended.
In order to cope with this complex user-agent audience, content authors and run-time systems need to dynamically adapt their applications to behave in different ways for different devices. Clearly, the success of this dynamic behavior depends greatly on the quality of knowledge that such individuals or systems have about those devices.
2.2 Device Descriptions for content adaptation
Although there are a number of clear benefits for the use of Device Descriptions in other use cases, and in other parts of the mobile industry, this Landscape Document primarily focuses on their use for content adaptation.
Content adaptation can be provided in a number of ways. The following four sections detail the common options and techniques, and how Device Descriptions are valuable in enabling these techniques.
2.2.1 Origin-server adaptation
If a web server or an application server is able to identify a mobile device sufficiently, it can draw on Device Description information to make decisions about how the content should be generated.
Content adaptation at the primary origin server is a very common technique, simply because it is at this end of the delivery chain that the degree of control over the content is at its greatest.
The need for Device Descriptions in the technique is significant. There must be an ability to be able to recognize the class of device from its request, and sufficient knowledge about that device's attributes to be able to perform appropriate, and valuable adaptation.
In the content server environment, it is often the case that a large, and unconstrained portfolio of devices will be accessing the content, with requests being relayed from a wide range of mobile networks.
This puts a particular demand on the ability of the server to recognize (and have Device Descriptions for) hundreds, if not thousands, of accessing device types. Alternatively there should be an ability for the recognition process to generalize and 'fallback' to the most similar device class for which it does have such Device Descriptions.
With correct and appropriate Device Description information, an origin server can potentially make radical decisions about the content, whilst easily retaining the application's integrity. For example, a server could choose to make whole sections of a site or application inaccessible if a Device Description asserted that those sections were beyond the capabilities of a client.
More refined decisions might include changes to the markup or binary structures of the content dispatched. For example, an origin server could easily switch between WML, CHTML or XHTML according to browser's known behavior. Different object formats can also be easily adapted at the origin server. For example, a server may decide to use images of different resolution or color-depth in a page if the handset's screen limitations are known.
Additionally, a significant amount of 'fine-tuning' of content can also be performed by a content server with a relatively low overhead. Cosmetic formatting, form layout, and other subtle markup attributes can easily be changed according to Device Description information.
One disadvantage of origin-server adaptation, on the other hand, is the complexity of setting up such dynamic behavior on the server. This approach is clearly not appropriate for static web content.
2.2.2 Delivery infrastructure
Content adaptation is also possible at points along the delivery chain between the origin server and the client. Many entities may be involved in delivering content across a mobile network in particular, and some of those, notably those in the IP-context, can perform on-the-fly adaptation of both the requests for the documents from, and the documents being returned to, the client through. These entities include WAP gateways, web proxies and dedicated transcoding platforms.
This 'smart proxy' approach to adaptation can be powerful, and can theoretically perform adaptation in as rich a way as can occur at the origin server. However, this comes at a performance cost, since the content may have to undergo a decompilation (or parse) and recompilation (or serialization) in order to be examined and adapted.
More importantly, there is an additional challenge to ensure that the context of the content is understood, so that the adaptation is relevant, and any changes made still reflect the origin server's intent. This may require a statefulness within the proxy which can be architecturally challenging. (For example, if a proxy provides large-page fragmentation for a device with memory constraints, any load-balancing techniques would need to ensure that successive requests for page fragments are serviced by a proxy that is aware of the device's previous page state).
The author's desire to be able to employ contextual information (e.g. descriptions of devices) is being addressed by new technical proposals such as DISelect [DISelect]
However, a real advantage of in-delivery adaptation is the fact that it allows the improvement, or device-awareness, of content that was statically hosted on its origin server, and which was not provided in a device-aware context.
The need for Device Descriptions for adapting content in the delivery chain is similar to the need within the origin server. A wide range of attributes about a device can be used effectively by the proxy, and, similarly to the content server, suitable adaptation relies heavily on the ability to recognize the device type.
In this regard, adaptation in the delivery infrastructure may benefit from the fact that a smaller range of device types are being serviced. A transcoding platform in a mobile operator's network will be able to assume, for most requests, that the device is one supported and provisioned on that network.
2.2.3 Client-side adaptation
Some device clients are capable of adaptive rendering. This technique involves the browser using information about its host device to decide how to best layout and display the content.
Whilst this is an approach that has real benefits for enabling the mobile web as a whole, a given browser installation, by definition, does not need to rely on multiple Device Descriptions. The browser only requires knowledge about the host device in order to perform client-side adaptation, although this can be either determined by the browser at run time or have been provisioned at design time by the browser manufacturer.
The scope of Device Description information required in this technique is likely to be a subset of that needed by server- or infrastructure-side adaptation. Naturally, the need to identify the device is reduced since it is the browser's host.
It should also be clear that the ability to perform structural adaptation of the content and application is reduced. The client can only adapt and render the content that has reached the device. It cannot augment that content, nor be aware of content that has not been yet retrieved, such as documents that the current page links to.
As a result, many Device Description attributes may be impotent in the client-side adaptation context. For example, although a content server is able to remove or rewrite links to unsupported document or object types, a client is unlikely to be even aware of the target document's or object's type. Device Description knowledge about which types are or are not supported is therefore less actionable.
2.2.4 Design-time
If Device Descriptions are provided in a sufficiently human- readable form, there is no reason why they could not be used for creating device-specific content in a design-time context.
For example, if a content developer is made aware of the differences between handsets when developing an application, it may be possible to integrate that knowledge directly into the content itself, and allow that human being to make sensible decisions about the nature of the adaptation required.
At the most basic level, this could involve creating two or more sets of parallel content for each group or genre of device. A single dynamic 'doorstep' page can redirect the handset to the correct content when the device first accesses the content. (Note that DDWG does not necessarily recommend this technique, since it has many disadvantages).
A slightly more scalable approach is to use Device Description information to create stylesheets of some kind (for example XSL) for each class of handset at design-time. This allows a better separation of content and its adaptation.
Regardless of the approach, the need for Device Description data is still significant at design-time. While it is less essential to articulate recognition knowledge to the designer, most other Device Description attributes can be utilized at this stage, particularly 'macro-attributes' which relate to devices' significant characteristics, features and document type support.
2.3 The users and providers of Device Descriptions
A broad range of organizations and individuals have a stakeholding in successful mobile web content delivery, and participate in the consumption and provision of Device Descriptions. This section details some of these parties and contributions, and should be read in conjunction with the Ecosystem Document sections on their roles.
2.3.1 Content Authors
Content authors are responsible for the primary authorship, development, or editorship of mobile content and applications. Authors are concerned that the content they create is properly represented to the user, regardless of device.
Even at the earliest stages of content origination, Device Description knowledge can be valuable. A journalist, for example, may even make editorial changes to mobile-destined content (such as front loading a news article) if aware of devices' limited screen or page sizes.
2.3.2 Web Developers
Web developers are responsible for integrating content into a web site or application so that it can be navigated and accessed. Their desire is to ensure structural integrity, navigational ease, and cosmetic consistency within a site, regardless of accessing device.
They use Device Description information both at design- and run-time to determine the amount, type and variations of content to provide.
For example, a developer can influence which links, navigational structures, and documents are provided on a device-by-device basis.
As a more superficial example, it is common for logos and icon be available in a number of different formats and sizes at design-time. Device Descriptions can be used to choose which images to use at run-time.
2.3.3 Aggregators
Aggregators gather content and applications from multiple developers or authors and present them to the user in a consistent and structured way. Many mobile operator portals for example, provide directory services linking to hosted, and external, content from a variety of sources.
Aggregators require Device Descriptions in the same way that web developers do, since the aggregator will typically be providing a site structure in which to place the aggregated links and content, and which should be successful regardless of the accessing device.
In particular, some aggregators choose to group together the content according to accessing device type. It is possible to find directories of content designed for one manufacturer's devices, or even for particular extraordinary devices. In these cases, Device Description knowledge may be required even when the choice of aggregated source is made.
2.3.4 Syndicators
Like aggregators, syndicators gather content from a variety of sources. However, that content is not necessarily ready for device consumption, having perhaps been syndicated in some machine-readable format.
Therefore Device Descriptions are required by the syndicator to be able to transform the machine-readable content into final device-ready markup.
2.3.5 Network Operators & Carriers
Operators provide the base IP infrastructure and cellular backbone for delivering content and applications to mobile devices. As the key provider of the mobility and telephony services for the mobile user, the operator has a great desire to ensure the quality of the overall user experience.
Operators commonly provide portals and content services of their own (which often both syndicate and rival products from the content providers described above), as well as much of the delivery infrastructure. Additionally, they often run third party developer and partner provider programs to encourage the authorship of mobile content for their users.
They are therefore important consumers of Device Descriptions for both origin server and proxy-based content adaptation.
In addition, most network operators have a high degree of control over which mobile device types (and subrevisions) are recommended for use on their networks, and generally type-approve and certify handsets beforehand. Many operators use this process as a way of obtaining their own Device Descriptions for use in various forms of content adaptation.
2.3.6 Infrastructure Vendors
A number of software vendors provide platforms designed to ease the process of adapting content for a variety of devices. These platforms often reside in the application-server (as an adaptation plug-in or transcoding layer), or in the delivery infrastructure (as a 'smart' proxy).
In both cases, a rich understanding of client capabilities is required, and many of these vendors provide Device Descriptions as part of their products.
2.3.7 Browser Manufacturers
A mobile handset device typically comprises a large number of software components, many of which are provided to the device manufacturers by third-party OEMs. These components might include operating systems, messaging clients, and, most importantly for this document, mobile web browsers. Some device manufacturers also develop their own client software.
These parties are important providers of Device Descriptions more than they are consumers, except in the case of client-side adaptation, where the browser itself will behave based on information about the host device.
2.3.8 Device Manufacturers
Manufacturers and vendors of handsets are typically well- known consumer brands, although some network operators offer branded handsets, which are often significantly different (at both a hardware and software level) from the base, non-customized model they derive from.
The device manufacturers are clearly responsible for the physical attributes and behaviors of the device, and are generally also responsible for the choice of browser that will run on the device.
They are therefore important providers of Device Descriptions.
2.3.9 Device Description Providers
Such is the importance of Device Descriptions to enable mobile data applications, that many commercial and open-source providers exist. These providers are not necessarily the manufacturers of the devices they describe.
These are primarily designed to offer Device Description data to content providers, web developers, and in some cases, infrastructure providers.
Notable examples in the open-source realm include WURFL (which provides standalone Device Descriptions, but also delivers a set of programmatic APIs for server-side content adaptation), and DELI, which assists in the usage of UAProf Device Descriptions.
2.3.10 Relevant Standards Organizations
The industry has already recognized that the need for Device Descriptions is an important one. Notably, W3C's CC/PP [CCPP] and OMA's UAProf [UAProf] standards are particularly relevant to this landscape.
2.3.11 Device Quality Assurance
As we have mentioned, network operators have an imperative to approve the quality of the devices that are launched onto their network.
In this realm, there are vendors of test and measurement equipment who assist in the generation of Device Descriptions from this process.
2.3.12 Content Quality Assurance
Both operators and content providers perform testing and quality assurance on the services they provide to end consumers, and a wide range of techniques and tools exist to do this.
In particular, some of these tools use Device Descriptions directly in order to simulate accessing devices, and to identify if the content response is compatible with those devices.