W3C International Workshop on the Implementation of a Device Description Repository
July 12-13 2006 Madrid, Spain
As the mobile web overcomes the limitations of network bandwidth and device usability constraints, there remains a technical challenge to present a consistent experience across the widest range of devices. The diversity of possible form-factors, combined with poor industry consensus on specifying and using device characteristics, has forced operators to solve content provisioning and delivery issues on their own. For an integrated operator, such problems are further amplified when considering the range of devices beyond mobile, such as portable devices proliferating in the office and home environments. Today device properties are mostly derived though a cumbersome and time consuming process of collecting and testing device property information one-by-one. While such an approach extends the reach of content across different devices - without compromising the quality of operator services - it leads to ad hoc processes that are difficult to manage, scale and share with partners. This position paper offers an integrated operator's perspective on some of the challenges, opportunities and problems facing a device description repository.
Abstract
1.0 Introduction
2.0 A Profile Database
2.1 Profile Validation
2.2 Version Control and Hosting
3.0 Conclusion
4.0 References
Standardized, accurate and up-to-date information on device properties would facilitate shaping and adapting content to diverse capabilities of terminal devices and multiple delivery contexts - thus eliminating one of the key roadblocks to better access to the web. Today content adaptation relies on custom solutions tailored to particular needs of specific mobile operators. This contributes to the fragmentation of the web into "walled gardens" in which operators have to guarantee the quality of content delivery to their customers.
Creating device Profile databases is nothing new. The Open Mobile Alliance (OMA) described a linear list of device properties UAProf based on the perceived needs of the industry. Unfortunately, UAProf adoption has been slow, in part because there are fragmented solutions and miss-aligned cost benefits between manufacturers, content providers and operators. As a result, UAProf is only used as rough properties guidelines for private Profile databases.
The MWI Device Description Working Group Ecosystem note outlines some of the business models surrounding the creation, maintenance and use of device descriptions. In addition, the DDWG has started to outline requirements for a single device repository with the key themes of: managing device description repository, query mechanisms, resilience, validation and accuracy of the supported device description to name a few. While both documents provide important touch-points for discussion, industry consolidation and agreement requires a great deal more work.
In reality, User Agent Profiles are a list of device characteristics stored in a database. On-the-fly access to entries enables content to be adapted to the end device (see Figure 1). In a perfect world there would be a current, valid and accessible database of all devices. Unfortunately, this is not the case. Instead there are numerous databases created and maintained privately and publicly with a range of properties and attributes. While the ultimate database is a worthy goal, the key objective for the France Telecom Group is to reconcile property descriptions, promote automated validation services and ensure that the datasets are accessible to its content providers and partners.
This position paper examines some of the above challenges, opportunities and problems from a perspective of an integrated service provider, with an understanding that the future mobile Web "ecosystem" could create win-win opportunities for all the players involved. This position paper focuses on just a few illustrative issues impacting the mobile device, browser and usage categories.
Database management is well understood. What needs to be determined is the nature of the content being accessed (public/private) and how that information is requested. What follows illustrates some issues.
Figure 1: A Single private Profile repository and access.
A common solution today involves a single private repository as illustrated in Figure 1. A request from a device is handled by an application server that makes a request into a private device repository. How the request is made and what is returned may - or may not - be standards compliant. Often content authors have no access to any device repository, consequently static pages/templates are created to support specific devices leaving many of an operators devices unsupported.
Figure 2: A hybrid model, multi-repository access.
In a configuration where there are public and/or private repositories as illustrated in Figure 2, a device contacts the content server for a particular page. The content server needs to know the device and browser capabilities in order to transform the content for the device. This process starts with a request to a publicly available root DDR server, which returns a Profile containing a pointer to another DDR server, that contains more specific information for that device. In this particular example, the public server knows that this is a mobile device and returns a pointer to the DDR for mobile devices which is hosted, for example, by OMA. Ultimately the content server fetches a third Profile from a private DDR, which could contain private, or proprietary device information.
Once the Profiles have been fetched from various sources, they can be merged into one Profile. The transformation engine then uses the device capabilities to transform the content into the appropriate device/browser specific mark-up. A typical set of transactions could be as follows:
Within the configuration illustrated in Figure 2 it is important to recognize that multiple DDRs may need to exist. Some may well contain generic device Profiles while others may contain private device information. Given the current modus operandi of UAProfile databases, it is highly probable that both private and public databases will have to be accessible and addressable. Consequently, from an integrated operators perspective it will be important for a standardization effort to incorporate such implementations into any proposed framework.
Access to a DDR needs to be designed to be as broad as possible with a range of supported API's. In addition properties that change over time are refered to as dynamic. The W3C has defined a framework; Delivery Context Interfaces: Accessing Static and Dynamic Properties DCI that address this exact issue.
It is imperative that Profiles be validated. A critical component will be machine validation with well defined rules and acceptance criteria. Manually created databases should be avoided because of an increased risk of introducing errors. Furthermore, as the size of the database increases a need for regression testing grows and without an adequate validation system in place, it is doubtful that manually created and maintained DDRs will be trusted by 3rd parties.
Based on a Profile the properties can be simply created within a XML format and transcoded to alternative formats on-the-fly. It will however, be important to create a commonly agreed upon core list of properties and definitions. Furthermore, it will be important to have an agreed upon definition of properties that make validation easy to perform and transparent enough to be machine accessible.
While Profile validation is non-trivial, there are a variety of different validators in existence that can serve as models. For example the RDF Validator and XHTML Validation services created and maintained by the W3C. More recently OMA have created a UAProf validation tool as a first step to public interfaces that allow anyone to validate the syntax of a Profile. While syntax validation of a Profile is important, it is only one aspect of a valid DDR. Clearly it is vital that properties in a Profile are complete, valid and up-to-date, this has be broken-down into it's constituent parts and consolidation and agreement by the industry is required to make this a reality.
With a public repository, the following version control issues need to be resolved:
The prevailing public perception is than an operator is ultimately responsible for the quality of service and overall user experience, irrespective of particular devices, platforms, applications and content involved in the service delivery. Operators recognize that the availability of a consistent, valid and trusted database of device information is critical. However, we believe a single consolidated database of device properties is unlikely to meet the needs of all the participants in the mobile value chain.
From an integrated operator's perspective, a hybrid "public/private" approach would be preferable, as most if not all operators are likely to use selected device properties and/or certain settings for customizing and optimizing content adaptation and delivery. As the underlying data may be critical to ensuring certain quality and consistency of user experience, operators are likely to keep such data private and insist on retaining direct control of its availability, accessibility, testing and provisioning. Consequently, it should be possible to access public device Profiles providing a common baseline of core device information, but allow for augmenting it with certain private solutions allowing for the necessary extensions or overlays.
It would be useful for the industry to reach a consensus on how a public database of core device properties should be designed, created, maintained and operated. The W3C could also help by facilitating an agreement on what such common denominator properties should be-- including the core properties already identified by the DDWG, for example, with regards to certain device features, screen characteristics, supported image formats, and markup languages, etc. It is also very important that a number of broad technical and operational questions regarding such a database and its environment be discussed in depth with a view towards eliminating at least some of the inefficiencies and overlaps of the currently existing private solutions. Specific issues that could be considered during the workshop include: