Device Description Ecosystem 1.0

1 Introduction

In the context of this Note, Device Descriptions are pieces of information relating to Web-enabled devices that may be used to categorize or distinguish these devices. In particular, this Note is concerned with descriptions of Web- enabled mobile devices and the characteristics detailed in such descriptions that may influence the delivery of content (resource representations) to them.

As an example, a description of a device may provide information about the type of markup supported by the browser, the size and resolution of the screen and the presence of various input features. A separate description of the same device might contain an evaluation of the usability of its keyboard, the usable area of the screen and the appropriate layout of the access keys. A third description might detail the most effective navigation strategies for the device, the best color schemes and the most readable fonts in order of preference. There may be many such descriptions. The information in these descriptions may overlap, may even conflict.

These descriptions can have various sources. Each source, such as a manufacturer or a usability group, will have different motivations for providing the information. The information could be in the public domain, or only available for a fee. The descriptions can be used in various ways. In particular, the descriptions of a device can influence the content delivered to the device. The descriptions could be used by content authors, and by the users (or potential users) of these devices.

In this environment there is a community of actors (stake-holders) who collaborate or compete within a web of relationships. The actors are motivated to benefit from these relationships, and over time these relationships will evolve. This is a social, commercial and technological ecosystem based on the exchange and management of device descriptions.

At the time of writing, the ecosystem is still in its early days. Models of exchange and management have yet to evolve and mature. Many actors are unsure of the roles they will play in the ecosystem, but there is general agreement that the availability of device descriptions will bring benefits to all of the stake-holders, in particular the participants in the Mobile Web.

This Note explores the current and evolving Device Descriptions ecosystem, and suggests a potential model for exchange and management.

2 Actors in the Device Description market

In this section we summarize the actors that currently play a role in the device description market, and those who are likely to play a role in the future. Each of these have different motivations for participating in the device description ecosystem. These are highlighted in each case.

2.1 Device Manufacturers

The manufacturers provide the key physical capabilities of the mobile device. Their manufacturing processes determine the size of the screen, the amount of memory, the speed of the processor, the networking features and more.

2.1.1 Motivation

By providing accurate descriptions of their devices, manufacturers can ensure that the features of their devices will be known to service providers, application developers, content authors and adaptation solutions, so that these features can be exploited. This should produce improved user experiences, raising the approval ratings of their devices, and thus leading to enhanced sales.

2.1.1.1 Unique Selling Point

One of the reasons for introducing new features/capabilities to a product is to make it more competitive. Encouraging the use of such features may lead to increased demand for the products. Publication of device features is a means of encouraging their use.

2.1.2 Current situation

Device manufacturers are not required to provide device descriptions. For mobile devices, such descriptions would normally be represented using the OMA's User Agent Profile technology, which is based on the W3C's CC/PP. If these profiles are created by a manufacturer, there is no requirement to store them in any particular place for public access, or even to advertise that they have been created. In some cases, the stored profiles have been found to be invalid according to the specifications of UAProf, or have contained inaccurate data, possibly because the device characteristics were altered during the design/manufacturing process without updating the profile before publication. Errors are not always corrected. Some useful device information has been contained within the profiles in the form of comments, which are inaccessible to automated processes.

The OMA is making efforts to provide better access to validation tools, and to provide a repository of validated profiles. This will provide manufacturers with a common management framework in which to facilitate their device descriptions. Facilities for augmenting or correcting the OMA repository are not provided, though the public access to the repository means that such facilities could be provided through third parties.

2.1.2.1 Absence of regulatory imperative to produce profiles

Manufacturers are not required to provide profiles of their devices. There is therefore no penalty for those who do not provide profiles. The availability of profiles therefore depends on other factors.

A regulatory imperative to provide profiles would guarantee their availability, but such regulations could only be imposed if their necessity could be clearly demonstrated. There is also the issue of identifying the appropriate regulatory body to enforce the regulations.

2.1.2.2 Absence of a standards imperative to produce profiles

There are no standards, necessary for the manufacture of devices, that demand the provision of device profiles. In fact, the only popular standard used by Web enabled devices that demands some communication of device capabilities is HTTP itself, in the form of the "accept" header. It is unfortunate that very few Web servers actually make use of the accept header. With this poor track record, it is not surprising to find that there is skepticism about the future of device description technology.

2.1.2.3 Commercial regulation

Agreements between operator and manufacturer so that devices must come with descriptions in order to be supported by the operator. Only works between big operators and big manufacturers.

2.1.3 Component manufacturers

The characteristics of a device depends on the characteristics of the components of which it is composed. Component suppliers do not contribute to the creation of device profiles. The principal manufacturer (or assembler) takes this responsibility.

2.2 Browser Vendors

Browser vendors provide content presentation software that may be installed at the time of manufacture, or at a later stage by the end- user via an installation process. The browser determines the presentation capabilities, including the type of markup, the type of image, sound or other media formats, and the modes of interaction.

Obviously, interaction may be limited by the capabilities of the device.

2.2.1 Motivation

Like device manufacturers, browser vendors are motivated by economic factors. By making the characteristics of their browsers known to the authors and adaptation solution providers they ensure that content can be presented to maximum effect. Good user experience should encourage more manufacturers or operators to adopt the browsers, and end users to install them.

There are also providers of browsers who are not motivated by economics, the open source community being a particular example. For these the motivation is typically a desire to demonstrate quality and professionalism while contributing something useful to their user community. Providing descriptions of their products is a simple way to advertise the features they are providing, and of ensuring that these features are used.

2.2.2 Current situation

Browser vendors are not required to provide descriptions of their browsers. Unlike manufacturers, there is no common technology with which they can provide descriptions. The UAProf vocabulary does not extend to include the specific features associated with the browser, although some vital information is supported. Only the content adaptors maintain descriptions related to browsers, and with the exception of the open source solutions, these descriptions are treated as commercial property. This is because of the effort involved in gathering and verifying information about the browsers, particularly as their characteristics can be affected by the device into which they are installed.

2.3 Device Validators

The handset validation sector is both a provider and a customer of device descriptions: they are gatekeepers of new handsets coming into the network. Although a lot of their knowledge of handsets is at lower radio levels, there is increasing service/application/content-level expertise.

2.3.1 Motivation

As both consumers and producers of device descriptions, the business of the device validator is dependent on device descriptions.

2.4 Accessibility Groups

The focus of the accessibility and usability groups is typically on software and services, rather than on the characteristics of the device. Nevertheless, there are certain device features that can be described by these groups, including:

Font-magnifier
Text-to-speech
Color schemes
Navigation layout
Keyboard usability
Special navigation keys
Navigation layout
Access keys

To illustrate how an accessibility/usability group might augment the descriptions provided by the manufacturer, consider the first item on the list: "font-magnifier". An accessibility group may determine that the built-in magnifier works best with sans serif fonts, which is information that might not be indicated by the manufacturer. This assessment would be made by specialists available to the accessibility group that would not necessarily be available to the manufacturer.

2.5 Content Adaptors

Because of the wide diversity of Web-enabled devices, a single representation of a resource will not be suitable for all devices in all delivery contexts. This has been well documented by the DIWG. Content adaptation solution providers use device descriptions as part of their content adaptation processes. Better device descriptions lead to better adaptations.

2.5.1 Motivation

Content adaptors are typically motivated by economic factors to maintain large and detailed repositories of device descriptions. The quality of their adaptations is directly influenced by the quality of the information in their repositories. Adaptation quality is a key selling factor.

2.5.2 Current situation

Content adaptors maintain large and complex repositories of device descriptions. They do this by gathering information from a number of sources, including:

Manufacturer specifications
UAProf data on manufacturer Web sites
Open source descriptions
Reports from new users
Direct assessment in their evaluation laboratories

Direct assessment is the primary source for some content adaptation providers, as it is the most reliable. This requires that their evaluation laboratories have physical access to new devices. In many cases, descriptions of new devices appear some time after the devices are released to the market, so there can be a lag between new devices appearing and optimum content being available.

2.6 Web Content Ratings

The W3C Mobile Web Best Practices Working Group has endeavored to provide guidance on the creation of content suitable for mobile devices. Among the general principals cited by the group are the exploitation of device capabilities to provide an enhanced user experience and the taking of reasonable steps to work around deficient implementations. To achieve this, the authors or content delivery systems need to be aware of the capabilities and deficiencies. Validators are proposed (and some implemented) by the BPWG to assess if the content on mobile sites are adhering to the suggested practices. Third-party services are also in place to provide similar assessment of content. The results of such assessments are typically ratings that can be advertised to potential content consumers.

2.6.1 Motivation

The providers of content rating services do so in order to encourage more and higher quality content in their aspect of the Web. For example, the BPWG provides content ratings to increase the amount of content that can be accessed via mobile devices. Other rating providers may do so to encourage higher quality content and/or to make revenue from the issuance of trust marks. Content authors make use of content rating services in order to improve the quality of their content, to make it accessible to a wider audience and to advertise this availability via trust marks or other certification mechanisms that indicate the ratings achieved.

2.6.2 Current situation

The BPWG has published a document entitled “mobileOK Basic Tests 1.0”, which can be applied to content to determine if it conforms with the “mobileOK Basic” requirements. It is expected that future tests will include cases where particular device capabilities can be used to their best advantage, which assumes that such capabilities can be determined. Third-parties are also providing similar content rating services to their respective communities.

2.7 Content Authors

Content author use device information to determine the amount, type and variations of content to provide. The information may be used at the actual time of authoring, or may be used at delivery time in a manner previously indicated by the author.

2.7.1 Motivation

Authors are concerned that the content they create is properly represented to the user. The fidelity of brand representation is significantly important to many commercial organizations. For example, it is common for branding purposes that a corporate logo will be available in a number of different formats and sizes. The variation in these images results from knowing the variation in device characteristics. For many, there is a compelling need to guarantee the accuracy of their content, especially when representing in complex layouts (e.g. timetables). The growing popularity of well-designed Web sites is further evidence of the attention that authors are giving to making optimal use of device capabilities, whether these be with respect to rendering, scripting, interaction or otherwise.

2.7.2 Current situation

Crude "browser sniffing" techniques provide many authors with the means of determining some of the general capabilities of the client into which the content is delivered. Many of these techniques are now being packaged into libraries for ease of use. Component-based authoring approaches also offer some degree of device capability awareness, where each component alters its representation according to the delivery context. Solutions that are aware of a large number of contextual parameters are generally only available commercially, though some free/open solutions are available that offer basic access to the delivery context. In general, the representations of context, and the interfaces to the data, are not interoperable across the various solutions.

2.8 Application Developers

Applications rely upon their operating environment to execute and interact with their users. The environment includes both the operating system and the hardware. With ever increasing varieties of environments, mainly due to hardware diversity, applications either have to be tailored to the individual environments or be capable of adapting when deployed into any environment. The latter is extremely challenging, so generally, applications are tailored in advance for the environments in which they are expected to operate. This applies equally to applications that run natively on the device and those that run within a browser. Application tailoring makes use of device descriptions.

2.8.1 Motivation

Access to device descriptions enables developers to create applications that are compatible with the broadest variety of environments. Developers either expect their development tools to be aware of device diversity, or be adaptable based on information they provide. For example, development tools that produce code compatible with PDA devices will typically be aware of the screen dimensions and orientation, or be capable of producing code that can adapt the screen layout based on screen properties discovered at the time of execution. With new devices appear regularly and developers are keen to see that these new devices are also supported because this represents new market opportunities for their applications.

2.8.2 Current situation

While many development tools are aware of certain kinds of device diversity, any significant change in capabilities introduced by new devices will usually require a significant upgrade to the tools. Modular development environments are easier to upgrade in this manner, since only those modules that are affected by the changes in device characteristics need be upgraded. Virtual Machine (VM) approaches are often used to overcome some device diversity (Java being a popular example) though often this involves gaining greater device compatibility at the expense of being unable to access new device features. The use of scripting in browsers is also extremely popular, especially with the growing use of the AJAX design pattern, though once again device diversity can present challenges. This is particularly challenging with the wide variety of interaction modes, which either requires increasingly complex scripts to be delivered to the browser, or some pre-adaptation to be performed by the server.

2.9 Operators

Network operators provide the means for conveying content to devices, and in many cases also provide the content. Mobile Network Operators are an example of content adaptors.

2.9.1 Motivation

Operators aim to provide a functional user experience [DIG] to their subscribers. They may also enforce content ratings policies. Device descriptions also assist in certification testing, and hence accelerate the release of the device to market.

2.9.2 Current situation

Multiple proprietary and commercial implementations are in use, with some having basis in standards such as UAProf and WURFL. Often the device descriptions include some operator-specific information, such as whether the device is part of a specific promotion by the operator.

2.10 End-Users

End users are consumers of device descriptions, and they can also influence device descriptions. They can enable or disable features, and in some cases can combine multiple devices into a composite (e.g. by adding a camera to a cellphone). End users are a source of preference information, which is another influencing factor in content selection or adaptation. This is why capabilities and preferences are handled by the same representation within CC/PP. End-user preferences, choices and combinations of features should complement the device description technologies.

2.10.1 Motivation

Users are particularly motivated by new features, whether it be because of the benefits that these features offer, or because of the enjoyment that many people get from something new. Users are therefore eager to learn of new features that are offered by new devices, and will often make comparisons between brands and models on the basis of competing features, as part of their purchasing decisions. Additionally, the ability of applications to make use of features may also influence their selection of devices and applications. Users are also being empowered to affect their devices by being able to alter the installed software, or augment the hardware. In this way, users have made device descriptions an increasingly dynamic issue. It is no longer possible to rely on the manufacturers' descriptions of their devices once they have been delivered to the end users. While some properties may be fixed (e.g. built-in keypad, screen, processor etc), many are user-configurable (e.g. browsers, memory, media players etc.). To adapt to such environments it is necessary to be able to determine the actual description of the device in real-time.

2.10.2 Current situation

Users tend to discover the properties of their devices through marketing material, rather than through an automated mechanism. Comparison shopping sites on the Web offer a break-down of features across brands and models. The need for easy comparison has led to the selection of units that are easy to comprehend, such as the number of different colors that can be displayed, rather than the number of bits per pixel, types of palette or any other measure of color capability. Access to dynamic properties (e.g. screen orientation) is being provided through various APIs for non-browser applications, though these may also be exposed to scripts in browsers. This is the goal of the W3C UWA WG's DCCI specification. Meanwhile, other organizations such as the OMA are working on similar problems [DPE].

2.11 Repository Providers

A repository provider offers a set of descriptions for sale, license or free unrestricted use. This information can be used for marketing purposes (e.g. comparison shopping), to augment the sales process of related products (e.g. games for mobile devices), to adapt content or applications according to the needs of the end user, to support emulators for use in test environments, to facilitate prototyping and many other uses.

2.11.1 Motivation

Given the many possible uses of device descriptions, repository providers will be interested in a common device description technology so that they can reach the largest possible customer base. For example, if a device description repository provider and the vendor of a device prototyping tool are to work together, it is essential that the interface between the two is compatible. Similarly, if the data representing the current description of a device (based on client-side analysis) is to be used on the server side, then they need to agree on a common vocabulary. Obviously there would be problems if the repository represented the usable screen width in millimeters while the client-side script determined this value in pixels. Compatibility and interoperability are therefore strong motivations for repository providers.

2.11.2 Current situation

In general, repository providers use proprietary formats and interfaces, and rely upon other developers to bridge any differences. Some providers employ UAProf in their repositories, though this limits the expressivity to the UAProf vocabulary. The DDWG participants include commercial and open source providers of device repository technologies and data who support the goal of a common interface and vocabulary.

2.12 Standards Organization

Standards organizations determine the interoperable means by which their participant members achieve mutually beneficial goals. The goals (e.g. efficiency) are generally perceived by the user community as positive objectives.

2.12.1 Motivation

The attainment of standards by the organization's membership can establish a defensible perception of quality that is attractive to consumers and acceptable to regulatory authorities (where appropriate). This enables products (that verifiably meet such standards) to operate in a consumer market and with a reasonable expectation that adherence to standards will attract customers.

Standards organizations capitalize on their members desires to benefit from standardization, and their members desires (pre-standardization) to ensure that the results of a standardization process will be in line with their current/planned products and services.

Since device descriptions are to be shared and used by many actors, interoperability becomes a key requirement, for which a standards organization is the natural facilitator.

2.12.2 Current situation

Although several standards already exist that have a significant bearing on device descriptions (e.g. RDF, CC/PP, etc.), the benefits to the participants in the standardization process have not been made obvious. Consequently it has been a struggle to achieve any standards, with barely enough done to demonstrate interoperability. The quality one normally associates with the use of standards is not evident in the case of device descriptions, and this is probably because of two reasons:

There is no regulatory body demanding quality of device descriptions in accordance with any particular standard.
The end users are unaware of any benefit to them that might derive from the availability of standardized device descriptions, and thus their buying patterns are unaffected.

2.13 Content Providers

Content providers are sources of content that is distributed to end users directly, through syndication or through partnerships. It is increasingly important that the content is accessible to end users regardless of the device they use to access the content and therefore some degree of selection or adaptation is required. This is done on the basis of known device characteristics. Where the content provider is not aware of the final delivery context, the authored content may be provided in a variety of forms to suit a variety of possible contexts. For example, the images accompanying a news article may be provided in various sizes at various resolutions.

2.13.1 Motivation

As content providers either have to react to delivery contexts in real time, or anticipate future delivery contexts, it is in their interest to determine the parameters of such contexts that may affect the way content is delivered.

2.13.2 Current situation

Content providers frequently use formats that are independent of the delivery contexts (e.g. RSS news feeds), and rely upon client software, or context-aware server software to adapt accordingly. In some cases, alternate content is provided (e.g. thumbnails of images, and short summaries of articles) to support a minimal degree of selection. As content providers increase the amount of content delivered to non-desktop environments, the need for context awareness is increasing.

3 Costs

There are costs associated with the provision, maintenance and use of information. This section summarizes the following:

costs borne by the actors in the device description ecosystem,
costs associated with the operation of the Device Description repository, and
measures taken to reduce costs.

3.1 Manufacturers

As the prime determinants of the device features, the manufacturer is an authoritative source of device descriptions.

3.1.1 Compiling profiles

To be useful to the developer community, a device profile must contain all of the key device properties and be correctly formatted. The properties represented in the profile come from different contributors to the manufacturing process. Creating such a composite profile involves coordination with these suppliers, which adds to the business management overheads. The data from the component suppliers may be in alternative formats, which will need to be translated to the common profile format. This adds to the complexity of the profile creation process, especially with respect to data validation.

3.1.2 Validating and verifying profiles

Many profiles are constructed together manually, which can introduce formatting or transcription errors. Profiles are intended to be machine readable and therefore need to be validated to ensure that they adhere to a standard format. Errors identified during validation then need to be corrected. There are only a few consumers of profile data, and these tend to identify errors through their own validation processes, which means the original suppliers of the profile may not be alerted to the original errors.

Validation is distinct from verification. In the former, the requirement is to ensure the well-formedness of the data, while the requirement for the latter is to ensure that the data correctly represents reality. Validation is a process that can be automated, and therefore the cost of validation can be reduced. Verification often requires human intervention because it deals with the relationship between a representation of reality, and reality itself. Verification is therefore more costly.

Suppliers of profiles need to inform the intended audience of the existence of the profiles. In the case of UAProf, the location of the profiles is given by a URL, which generally points to the manufacturer's Web site. This means that the maintenance of the profiles must form part of the Web site management process. This management function may also include the creation of summaries, or the depositing of profiles into central archives, such as that maintained by the OMA.

3.2 Authors

This section deals with the costs associated with authoring of content.

3.2.1 Awareness and Discovery

Authors who use device descriptions incur a cost for searching for new descriptions or sources of descriptions, and discovering how this information may be used. The benefit to the author is higher quality content. For such authors, they may equally consider the cost of not being aware of device descriptions, and therefore they prefer to incur a lesser cost to be able to discover updates (e.g. a subscription service) or make regular checks on available sources (e.g. updated open-source material).

3.2.2 Tooling

Tool vendors have identified the advantage of have client-sensitive features in their tools. This includes content previewers and device emulators, and some adaptive technologies. These tools must be delivered with built-in device knowledge, or have some way to obtain updates as new devices are released. This represents a cost to the tool vendor, which is typically passed on to the customer (the content authors and service providers).

3.3 Repository costs

The provision of a Device Description repository necessitates the provision of a physical infrastructure and operational overheads. For example, the repository will require storage, backup, processing and communication facilities.

4 Benefits

This section summarizes some of the benefits that derive from the availability of device descriptions.

4.1 Better quality presentations

The increasing diversity of Web-enabled devices means that a "one size fits all" approach is unlikely to achieve the optimal experience on all devices. Instead, the different characteristics of the user agents and devices need to be considered. With the aid of an adaptation technology, supported by reliable contextual information, the quality of the the end user experience can be greatly enhanced. This is particularly noticeable in the quality of content presentation: banners fit the screen, tables and lists are properly laid out, the default input mechanism for forms is appropriate to the available input modalities, there are fewer errors (e.g. attempting to use a feature that is not supported by the device) and so on. This provides the users with positive experiences and encouragement to continue using their chosen devices. It also gives users the confidence to try new devices with new functionality.

4.2 More efficient use of bandwidth

An adaptation technology can use device descriptions to select only the forms of content that are compatible with the requesting device, thus avoiding the waste of bandwidth that might occur otherwise. Images can be sized or cropped in advance of delivery. Similar optimizations can be applied to streamed media (e.g. by choosing the codec according to known performance for the delivery context). These efficiencies result in faster delivery times and reduced request latency for the end user, and the ability for the network operator or service provider to support more users or services.

4.3 Enables better support for new devices

New devices offer users with new or improved features. These are of little benefit to the users if the content or data delivered to the device makes little or no use of the enhancements. For example, if a new browser is introduced that has the ability to establish a mobile video conference via a hyperlink in the page, this may be an appealing feature until the user discovers that all the conference-enabled services are still giving manual instructions to initiate such calls. In this case, the user has a reasonable expectation that the new feature will be used as advertised, to justify the cost of the upgrade. This may be achievable if the manufacturer advertises the new feature via a common device description repository, and all adaptation solutions can access this repository to update their adaptation processes.

5 Competition

This section examines how device description suppliers compete with each other. The presence of choice and competition in an ecosystem is considered to be beneficial.

5.1 Trust

Trust is a subjective concept related to the integrity or ability of something or someone. It is difficult to measure, compare or define values for trust. For the purpose of this Note, a device repository that is perceived by users to be more reliable, stable and accurate shall be said to be trusted, and the stronger this perception the greater the trust.

It is inevitable that repositories will contain errors, of varying severity. Those responsible for the repositories will have varying responses to reported errors. Some will permit users to make corrections themselves via a system to check and update data, possibly acting on a local instance of the repository. Other providers will require a more formal process to be followed, especially where the repository is managed centrally. A good mechanism for addressing repository errors will improve trust in the repository.

Repository providers can distinguish their products on the basis of trust. For some users, the ability to contribute corrections where necessary will be seen as trust enhancing. Additionally, the presence of a formal process for validating contributed corrections will increase perceived trust, even for those who are not the contributors of corrections.

Support for repository users also improves trust. This can come in the form of a provider/vendor offering support for a fee, or a community of users offering mutual support.

5.2 Accuracy

Errors occur in many places. In the case of device descriptions, the following need to be addressed by the suppliers in order to maintain a sense of accuracy, which increases trust:

Are there errors in the data?
Are errors corrected? If so, how fast?
Has the data been approximated or normalized? Will this have consequences for the consumer?
Is the data based on samples? How representative are these samples?

5.3 Price

There are two main business models to consider. In the commercial model, there are vendors of data repositories that generate revenue by offering quality-assured information and providing support for these products. In the open source model, the community offers data repositories in return for further contributions to the repository.

In the case of a commercial product, the price is expected to be commensurate with the quality of key features (accuracy, scope, depth, etc.). Vendors can compete by varying the prices. The commercial value of the repositories is measured by the revenue generated through sales.

In the open source model, the monetary price is zero. However, there is a reasonable expectation that those who benefit from open source repositories would respond by making contributions in kind. This could be in the form of additional device data, validation of existing data, the provision of documentation, translation of documentation, implementation of interfaces etc. All of these contributions have a commercial value, and the commercial value of the repositories (although unmeasured) is - at least - the sum of the values of the contributions.

Customers of commercial repositories generally expect that the price paid will ensure that the responsibility for maintenance of the repository (e.g. correction of errors) will rest with the vendor. Users of open source solutions, while benefiting from a significantly lower price, form part of a community that collectively bears responsibility for maintenance.

5.4 Relevance

Do the descriptions relate specifically to my business? There is no point in offering descriptions that have no relevance.

Specialized information providers may offer device descriptions that are filtered according to their relevance to a specific purpose. For example, a specialized repository may offer details on the color gamut of mobile displays. This niche information may be relevant to creators of mobile images.

In time, it is expected that basic device information will become more widely available, but there will still be a demand in specialized areas for specific device information. There is an expectation that the general and the specific repositories will be compatible (in the way data is accessed and the way information is represented). In this way, the specific repositories can be seen as compatible extensions of the general repositories, with all the benefits this evolutionary path provides.

5.5 Scope

Are the data restricted in any manner? Sample restrictions in scope include:

Geographic regions
Device classification (size, feature, price etc.)
User type (fashion, teen, executive etc.)
Service type (news, messaging etc.)
Temporal (e.g. only the devices manufactured since YYYY)
Operator partnership

The supplier may have other arbitrary restrictions that reduce the size of the collection of data, typically accompanied by a lower price. If this data is specifically relevant to the data user's market, then this becomes an attractive idea.

5.6 Depth/Detail

Is the data limited to a few pieces of essential information per device, or are there hundreds of different data? In some cases (e.g. the download of mobile software) the minute details of the device can be important. In other cases, such detail is irrelevant. In a generic authoring environment, where the author can influence the adaptation of content based on any available contextual data, having a broad range of data in the repository may be beneficial (or at least perceived to be so). In pre-configured adaptation solutions where the necessary contextual data is known in advance, a repository that only holds that particular data may be advantageous (i.e. less overheads, less maintenance and potentially better performance).

5.7 Availability

Providers may compete on the availability of their repository data. In some cases, the data is immediately available, especially if it is hosted on a public server. Alternatively it may be available from a server following a short registration and/or payment step. These are high-availability scenarios and may be more attractive to repository users than other sources of data that involve greater delay. For example, an instance of a repository may be delivered physically on various storage media for installation by the recipient.

Users of repositories may also be concerned about the frequencies of updates. Updates are necessary when a new device becomes available, or corrections are made to existing data, or when new categories of data are introduced. The time between updates becoming necessary and the data user having access to the updated data may have a bearing on the decision to use a particular source of data.

6 Trust

Trust is a value we place on data. When offered two or more sources of data that offer the same information, we choose the source with the highest trust to increase the chance of getting good information from the data.

The issues to be resolved include:

Representing the trust values.
Determining trust values for information sources.
Communicating trust to the data consumer

Consider the following scenario:

Manufacturer M provides a highly portable device with a built-in keyboard. Service provider S wants to deliver an interactive form to M and will choose a menu-based solution or a text-entry solution based on the keyboard usability. User U has indicated no particular preference for stylus, buttons or keyboard. Accessibility group A has rated M's keyboard as poor, while M has rated the keyboard as excellent. How should S proceed?

In the above scenario, S may decide that M has a reputation for good usability testing and is honest in its descriptions, whereas A has a tendency to be over-critical. Thus S trusts M's description more that A's, and therefore chooses to send a form to the device requiring the user to enter some text into a field.

Alternatively, S may have no opinion about the trustworthiness of M's descriptions, but knows that the government has suggested A's usability assessments be used whenever possible. In this case, S will choose A's judgment and chose to deliver a sequence of simple menus to the device to avoid the user having to type text.

The scenario above highlights a problem with subjective descriptions (such as the usability of certain device features) since any such descriptions can only be the opinion of the people who created the description. However, a similar problem can occur with data that appears to be objective. The size of a screen would appear to be an objectively measurable value. Yet, to the manufacturer it means the number of pixels present in the screen, while to the content author it means the subset of those pixels that can actually be used to render content. The two values are often different. One could attempt to derive "usable size" from "physical size" but now you have introduced a processing step in the acquisition of information and you will need to consider the trustworthiness of this processing. Thus, any variability in the interpretation of the data can lead to discrepancies and loss of trust.

Trust is important when critical decisions must be made. Selecting between two sources of data is one such decision. Choosing between a number of adaptation options in critical phases of interaction with the user, is also trust-related. For example, your service is delivering a map (or an X-ray medical image, or security picture from a remote camera or any other fidelity-sensitive image) to a mobile device, and you have information from a moderately trusted source that the device will scale rather than clip the image. Do you, or do you not, adapt the image on the server before transmission? The consequences of making the wrong choice could be significant.

6.1 Trust the source of information

There is a relationship between the trust you assign to an instance of data and the trust you assign to the source of that data. Generally, the more you trust the source, the more you will trust the data. New data produced by a source will initially be trusted to the same degree as the source itself. When data is subsequently used, the quality of that data can be evaluated. If the results of using the data are good, this can improve the trust one puts in the source. Similarly, if the results of using the data are bad, this can negatively affect the trust in the source.

The trust one associates with a source can be affected by the proximity of the source to the origin of the data. For example, a manufacturer of a display screen may be highly trusted with respect to objective technical details of the screen, such as its dimensions. A retailer of devices in which many screens are used might be trusted less because the retailer was not involved in the manufacture of the screens.

6.1.1 Missing information

The information provided by sources is never complete. There are several reasons for missing information, including:

Costs associated with gathering, verification and publication.
Lack of access to the origin of information.
Concern that revealing some information that may be perceived negatively. In particular, information about device limitations or known erroneous behavior is something that some manufacturers may be cautious about making public.
Belief that certain data would not be valuable, and therefore not worth publishing.
Delegation of responsibility for publication of some of the data to other authorities.
Mistakes made by the collators of the data.

6.1.2 Other issues related to trust of sources

There are many other sources of trust issues with respect to the sources of device information. These include:

Information coming from multiple sources (e.g. component manufacturers) that needs to be merged into a single set, especially where conflicting data occurs.
Errors due to bad timing, faulty communications or other sources, and errors in legacy data.
Data that derives from subjective assessments can lead to conflicts, especially where the criteria for such assessments are unknown.

6.2 Trust how information is used

This section briefly mentions some issues relating to the use of device information.

6.2.1 User preferences

Sometimes considered as a property of the device, the settings that relate to user preferences are not considered part of the device description. What can be part of the description is the ability to be influenced by user preference. Whether or not the state of the device can then be revealed to a third party can give rise to trust concerns.

6.2.2 Implied user properties

The implication of some device properties is that the end-user may be categorized. For example, the presence of a screen reader would be seen as implying that the user was visually impaired, and this information could influence the content/service provider (e.g. a health insurance provider offering a service via the Web).

6.2.3 Legal restrictions

There may be cases where applicable laws influence the availability and use of device information. A system offering device description may need to consider such restrictions. (See the previous example.)

6.2.4 Jurisdiction issues

Given that it may be possible for a device description solution to operate across jurisdiction boundaries, there may arise concerns over the applicability of regulations to the operation of such services.

6.3 Trust the fidelity of forwarded information

What happens to cached information? Will it go stale? Will forwarded information be delivered verbatim, or will an intermediary be permitted to summarize/aggregate?

Many of these issues are addressed by established information security technologies. However, their implementation raises some overheads (e.g. the calculation of digital signatures), which will impact both the cost and the efficiency of the DD repository.

In a working ecosystem, those demanding trust must place a value on this trust and therefore accept the associated overheads.

7 Architecture and Deployment

The provision of a Device Description Repository is not without costs. This section notes some architectural models for the repository, the manner in which these architectures are deployed, and the costs involved. This is neither a recommendation for any particular architecture, nor an exhaustive list of the options.

7.1 Centralized Repository

This architecture realizes the repository as a single instance deployed in a single place with all access via the same networked connections. Management of the solution is simplified because all operations are applied in one place.

The cost of this single instance is high because of the number of users that are served from one place, requiring superior processing capability, high bandwidth and permanent "up time". This single instance is also a single point of failure and there will be significant costs if the system fails.

7.2 Distributed Mirrors of a Master Repository

This architecture is a simple extension of the centralized repository, where updates to the master are replicated to all of the mirrors. As most of the operations will be reads, the updates can be directed to the master, while the reads are handled by the mirrors. This spreads the networking and processor load, and reduces the down-time risk. In the event of a failure of the master, one of the mirrors can be designated as the new master.

The cost of this architecture is greater than a centralized solution (because of the management and replication overheads), and roughly proportional to the number of mirrors. There is less potential cost due to system failure. The mirrors may share the cost burden.

7.3 Multiple Independent Repositories

Unlike the central/mirrored architectures, this architecture permits device descriptions to be collected, managed and queried independently. There is no requirement for the same data to be available from all instances, nor is there a requirement for the values stored to be consistent. The instances may use the same APIs, and even the same vocabularies, though it is more likely that each instance will specialize in some aspect of device descriptions and therefore they will employ their own vocabularies.

This architecture is at least as costly as as the centralized architecture. The instance with the most useful (and/or least expensive) data will bear the heaviest load. Failure of any individual repository will be serious for any users of that repository because it is unlikely that an alternative repository will have the same data.

This is the situation that pertains at the time of writing, though the instances all use their own vocabularies and their own interfaces. In some cases, the interfaces are merely HTTP requests for XML files, and in other cases the interfaces must be provided as custom code because only the repository data is accessible (as a single file).

7.4 Distributed Disjoint Delegated Repositories

This architecture is similar to the Multiple Independent Repositories architecture in that each instance has a separate collection of data. However, the instances are managed so that the aggregate data is equivalent to that managed by a Centralized Repository. Furthermore, each instance is capable of redirecting, or proxying, to an alternative instance if it is queried for data that is not in its vocabulary.

The costs of this architecture are similar to the Multiple Independent Repositories architecture, though probably a little more due to the need to manage the delegation.

7.5 Distributed Delegated Repositories with Redundancy

This architecture is similar to the Distributed Disjoint Delegated Repositories architecture except that each instance is permitted to mirror some data from other instances. This reduces the need for redirects or proxying, improves latency, improves resilience and reduces risk due to the failure of an individual instance.

The cost of supporting this architecture is shared by all instances. Mirroring (caching) enables the load to be balanced across instances, reducing the need for extreme processing or networking capabilities, and providing redundancies in the data collections which reduce the likelihood of costs due to instance failures. It is even possible to distribute the management and maintenance costs associated with data collection, mirroring and delegation of requests.

7.6 Hybrids and more

Any of the above architectures can be combined to some degree. For example, several independent repositories can coexist with a distributed delegated collection. Lessons from the field of federated databases suggest that many alternative models are possible and are likely to be explored by implementers of Device Description Repositories. These are not explored in this document.