Copyright © 2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This W3C Working Draft specifies the requirements for a logical reference repository for device descriptions. This document does not specify a definitive list of device descriptions rather it specifies requirements not only on the reference device descriptions repository itself but also on the provision and management of device descriptions, and the discovery and access to the repository and its device descriptions.
This document forms one of three W3C notes within the scope of the W3C Mobile Web Initiative, Device Description Working Group (DDWG). The requirements in this document are not only derived from the described use-cases but also build on the information described in the DDWG Landscape [DDLAND] and Ecosystem [DDECO] documents.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This document is a First Public Working Draft and has been produced as part of the W3C Mobile Web Initiative, Device Description Working Group (DDWG), following the procedures set out for the W3C Process. The authors of this document are members of the W3C Mobile Web Initiative, Device Description Working Group (members only). Feedback can be directed to the DDWG Public Mailing List, which is also archived.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
(Informative)
1.1 General
1.2 Conventions
used in this document
1.3 Definitions
1.4 Abbreviations
2 Use Cases (Informative)
2.1 Use-case 1.
Utilization of device description information from the
DDR
2.1.1 Overview
2.1.2 Actors
2.1.3 Pre-conditions
2.1.4 Post-conditions
2.1.5 Normal Flow
2.1.6 Alternative Flow 1: Device Description not
available
2.1.7 Alternative Flow 2: Capability not identified
within a device description
2.1.8 Alternative Flow 3: Utilizing available device
description to allow content subscription
2.1.9 Alternative Flow 4: Utilizing the device
repository for tailoring pushed content
2.2 Use-case 2.
Tailoring primary source of content for specific device
ranges
2.2.1 Overview
2.2.2 Actors
2.2.3 Pre-conditions
2.2.4 Post-conditions
2.2.5 Normal Flow
2.2.6 Alternative Flow: Query of device
description
2.3 Use-case 3.
Availability of a new Device Description
2.3.1 Overview
2.3.2 Actors
2.3.3 Pre-conditions
2.3.4 Post-conditions
2.3.5 Normal Flow
2.3.6 Alternative Flow 1: Replacement of existing
device description
2.3.7 Alternative Flow 2: Modification and updating of
existing device description
2.4 Use-case 4. Device
Repository query capability
2.4.1 Overview
2.4.2 Actors
2.4.3 Pre-conditions
2.4.4 Post-conditions
2.4.5 Normal Flow
2.5 Use-case 5.
Using device descriptions from both a public and a private
repository
2.5.1 Overview
2.5.2 Actors
2.5.3 Pre-conditions
2.5.4 Post-conditions
2.5.5 Normal Flow
3 High-level DDR functional requirements
(Normative)
3.1 System
requirements
3.2 Interface
requirements
3.3 Query
requirements
3.4 Notification
requirements
3.5 Versioning
requirement
3.6 Validity
requirements
A Acknowledgements
(Non-Normative)
B References
(Non-Normative)
This document specifies technology neutral requirements for a reference repository for device descriptions, which in the context of this document are understood as pieces of information relating to Web-enabled devices that may be used to categorize or distinguish the capabilities of these devices.
This document derives requirements for a single logical device descriptions repository, and the environment in which it operates. In particular, as described in detail in the DDWG Landscape and Ecosystem documents the requirements focus on several key themes:
The extensibility and capacity capabilities of a device descriptions repository.
The device decriptions repository query, access and management mechanisms.
The availability and resilience of the device descriptions repository.
The extensibility of the supported device descriptions.
Simplicity in the format and storage of the device descriptions.
Validation and accuracy of the supported device description information.
The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "required", "may", and "optional" in this document are to be interpreted as described in RFC 2119.
The following definitions, in addition to terms from the Device Independence Glossary [DIG] are used in this document.
An Actor in the context of the Device Descriptions requirements document is any actor that belongs to the device description ecosystem as described in the Device Description Ecosystem document [DDECO].
A representation of one or more Device Properties associated with a device.
The DDR is a single logical entity, comprising one or more repository components, which exposes a single clear common interface for the purpose of providing access to device descriptions.
A Delivery Context Characteristic, from an extensible vocabulary, associated with a device that describes a capability or behavior of the device. A Device Property may be a key/value pair or a tuple.
This section is informative.
This use case describes a basic scenario where an end-user consumes web content from their device. Prior to delivery, the requesting device (or the end-user) provides the means for a Content Provider to identify the device, accurately determine the supported properties of that device by utilizing the device description contained by the device repository. The Content Provider can then deliver content in a form most suitable for that device.
End User: The end-user uses their device to consume content or services that they request. The end-user expects a good user experience when consuming content from different Content Providers, e.g. served content is displayed correctly on the device.
Content Provider: The Content Provider provides content and services for end-user consumption. The Content Provider has the ability to determine the capabilities of an end-user's device and to tailor the content appropriately for that device. The Content Provider utilizes the available device description information to provide a good experience for end-users consuming their content;
Device Vendors: The Device Vendor develops device descriptions for their devices. These device descriptions typically describe the supported capabilities of a device, e.g. screen size, camera capabilities, markup languages etc). The Device Vendor makes available and maintains for accuracy device descriptions for public usage, e.g. by Content Providers.
Device Description Repository: A DDR is accessible and allows for queries and retrievals of device description information. The DDR contains device descriptions that are accurate and a true representation of a devices capabilities;
End-user: The end-user has a device for which a device description is available and which can be queried from the DDR.
Content Provider: The Content Provider has the ability to identify the end-user's device and is able to query the DDR to retrieve device description information for that device. The Content Provider utilizes the resulting device description information for the tailoring of their content and services.
Device Vendor: The Device Vendor develops, manages (e.g. updates existing device profiles when devices are upgraded) and makes available through the DDR accurate device descriptions for their devices.
End-User: The end-user consumes a tailored service optimized for the capabilities of their device and has good user experience.
Device Vendor: The Device Vendor provides device descriptions for their devices allowing, for example, Content Providers to accurately tailor content utilizing the capabilities of the device. In essence the Device Vendor provides added value to the Content Provider's services
Content Provider: Through the available device description the Content Provider determines a device's supported capabilities. The Content Provider serves content that is tailored appropriately for the capabilities of the end-user's device.
The end-user launches the browser from their device, navigates available Content Provider services, then selects a link (URL) that initiates a request for a particular service;
During the request for service the end-user's device provides its identity (e.g. through the supported User Agent Header) to the Content Provider;
The Content Provider receives the request for service and the identity of the requesting device;
Using the identity of the device the Content Provider queries the DDR to determine one or more capabilities supported by the device;
When the DDR receives the query it performs a look-up of available device descriptions;
The DDR returns the results of the query, which are used by the Content Provider to tailor the content in a manner best suited for the device;
The Content Provider then serves tailored content to the end-user;
The user consumes the served content and receives good user experience.
Same as Normal flows 1 to 5;
The DDR is unable to identify the appropriate device description and is therefore unable to return a result following the query;
The Content Provider needs to take appropriate course of action, e.g. either serves default content that is adequate for the range of devices;
The user consumes the served content and may not receive the best user experience;
Same as Normal flows 1 to 5;
The DDR identifies the appropriate device description but it unable to determine the requested capability information (e.g. the DDR is unable to determine the support of a specific streaming media format) and is therefore unable to return a result following the query;
Same as Alternative flow 1 steps 1 and 2;
The end-user attempts to subscribe to a service offered by the Content Provider;
Same as Normal flows 1 to 5;
The Content Provider authorizes end-user subscription and serves tailored content to the end-user;
Same as Normal flows 8;
Before delivering content (e.g. news update) via a Push message to an end-user (i.e. consumer of the content), the Content Provider queries the DDR to determine one or more capabilities supported by the device, which is already known to the Content Provider;
Same as Normal flows 2 to 6;
The Content Provider then pushes the tailored content to the end-user.
This use case describes a basic scenario where a Content Adaptor tailors single representation of content (i.e. content that has not been specifically adapted or tailored) for a specific range of devices. The Content Adaptor requests from the DDR a device description information for a specific range of device and based on results of the request tailors the content accordingly.
Content Developer: The Content Developer develops and makes available a primary source of content for end-user consumption. The Content Developer develops content that is not tailored or best suited for particular devices but relies on third parties such as Content Adaptors to perform the required content tailoring
Content Adaptor: The Content Adaptor utilizes device descriptions as part of their content adaptation processes. The Content Adaptor has the ability to determine the capabilities of a range of devices and tailor and adapt primary source of content in a manner appropriate for the capabilities associated with different ranges of device. The Content Adaptor needs to be confidant that the results to their query is accurate (i.e. the device descriptions represent the exact capabilities of a device) and provides enough information to allow for quality adaptations.
Device Description Repository: A DDR is accessible and allows for queries and retrievals of device description information. The DDR contains device descriptions that are accurate and a true representation of a devices capabilities;
Content Adaptor: The Content Adaptor queries the DDR and utilizes the resulting device description information to tailor and adapt Content Developer's primary sources of content. The Content Adaptor has the ability to request (and retrieve) from the DDR information pertaining either individual devices or a specific device range. The Content Adaptor has the ability to make a request pertaining to either the whole of a specific device description range or part (e.g. screen size) of a device description range.
Content Adaptor: Using the results of the DDR query the Content Adaptor tailors the Content Developer's primary source of content in a manner suitable for a specific range of devices.
End-user: The end-user consumes a tailored service optimized for the capabilities of their device and has good user experience.
The Content Adaptor initiates a query to the DDR requesting a device description for a specific range of device;
When the DDR receives the query it performs a look-up of available device descriptions;
When the appropriate device description has been identified the DDR returns the device description to the Content Adaptor;
The Content Adaptor receives the device description and tailors the content in a manner best suited for that range of device;
The Content Adaptor may either provide the tailored content back to the Content Developer or provide the tailored content to third party service provider, e.g. Mobile Operator.
The tailored content is consumed by end-users and they receive good user experience.
The Content Adaptor initiates a query to the DDR requesting specific information pertaining to a device description for a specific range of device, e.g. to determine whether a device range supports streaming or video camera;
Same as Normal flow 2;
When the appropriate device description has been identified the DDR returns the requested information as determined by a query of the appropriate device description;
Same as Normal flows 1 to 6.
This use case describes the scenario where a Device Vendor (or other appropriate actors such as an open-source Framework Provider) creates and makes available a new device description, which is an accurate description of the supported capabilities of a device. The creation of the new device description may be because of the development of a new device or because of the version of an existing device has upgraded.
Device Vendor: The Device Vendor develops device descriptions for their devices. These device descriptions typically describe the supported capabilities of a device, e.g. screen size, camera capabilities, markup languages etc). The Device Vendor makes available and maintains for accuracy device descriptions for public usage, e.g. by Content Providers.
Device Vendor: The Device Vendor develops, manages (i.e. updates existing device profiles when devices are upgraded) and makes available through the DDR accurate device descriptions for their devices.
Device Description Repository: A DDR is accessible and allows for queries and retrievals of device description information. The DDR provides the ability for authorized users to upload new device descriptions and also provides the ability for existing device descriptions to be managed (e.g. extended, modified, archived).
Device Vendor: The Device Vendor generates an accurate device description and has uploaded the device description to the DDR
Device Description Repository: The [DDR] has stored and is made aware of the device description (i.e. the [DDR] is able to query the information), which is now available for public consumption, e.g. Content Adaptors and Mobile Operator's can query the information.
A Device Vendor creates a new device description and uploads it to the DDR;
The DDR receives the new device description and stores the device description in the appropriate folder (e.g. Vendor specific folder, Validated folder etc);
The DDR may also manage existing device descriptions during the upload of the new device description (e.g. the DDR may manage existing device descriptions and folders by archiving old versions of the same device repository;
The DDR then makes available the new device description for public consumption;
The Content Provider (or any actor requiring device description information) is able to query the new available device description.
The Device Vendor wishes to update one of their existing device descriptions (e.g. existing device description updated to indicate the support of new MIME type);
The Device Vendor creates a new version of an existing device description and uploads it to the DDR
The DDR replaces the old version with the new version of the device description. For backwards compatibility purposes the DDR applies version control including change history to each device description and each version of the device description;
Same as normal flows 2 to 5.
Same as Alternative flow 1 step 1;
The Device Vendor issues a request to the [DDR] to update an existing device description (e.g. a request to indicate the support of new MIME type);
When authorized (e.g. the actor requesting an update may need to submit personal details for audit and non-repudiation type purposes) the Device Vendor updates the existing device repository indicating support for the new MIME type;
Same as Alternative flow 1 steps 3 and 4
This use case describes the ability for a Content Adaptor (or any other actor within the device description ecosystem such as a Mobile Operator) to query the DDR for the purpose of obtaining information from the available device descriptions. Queries can be used to determine, for example, the number of devices that support video cameras, are members of defined sets (e.g. PDA) or other specific features. Information from queries can be used to assist content authors, marketing or other analysis such as determining the number of devices supporting certain types of markup.
Content Adaptor The Content Adaptor needs the ability to query the DDR to determine the number of devices in the market place that support one or more device capabilities to identify the number of primary source content adaptations they need to perform. The Content Adaptor expects the results of their query to be both accurate and trust worthy.
Content Adaptor: The Content Adaptor has the ability to query the DDR and receive the results of the query.
Device Description Repository: A DDR is accessible and allows for queries and retrievals of device description information.
Content Adaptor: The Content Adaptor queries the DDR requesting information for number of devices that support, e.g. SVG-T. The Content Adaptor receives the results of their query and utilizes the results for their own purposes.
Device Description Repository: The DDR receives the request for information and queries all available device descriptions to identify the necessary capabilities. The DDR returns the results to the requesting actor.
The Content Adaptor initiates query to the [DDR] to determine the number of devices that support XHTML;
When the [DDR] receives the request it performs a query of all available device descriptions;
When the query is complete the [DDR] returns the results (e.g. a list of device types that support XHTM) to the Content Adaptor;
The Content Adaptor receives and utilizes the results for their own purpose.
This use case describes a basic scenario where a Content Provider adapts content for delivery to a client device on the basis of information selected from two sources. The Device Description Repository Administrator determines that information within a specific concept domain shall be obtained from a source other than the default source. A Repository Provider makes the domain specific information available to the Content Provider. In this use case the domain specific information relates to menu layouts on devices.
End User: The End-User uses a device to consume content or services requested from the Content Provider. A good experience is expected when using the device. The End-User is particularly interested in the ease with which the content can be navigated.
Content Provider: The Content Provider provides content and services for end-user consumption. The content and services are tailored according to the capabilities of the end-user device. To enhance the quality of presentation for some end-users, the Content Provider has additional information about menu layouts on a particular set of devices, which is employed during adaptation.
Repository Provider: The Repository Provider provides a repository of device descriptions that are specific to a certain domain. In this use case, the domain relates to recommended menu layouts for each device, based on hands-on evaluations. The Repository Provider may offer access to this domain-specific repository on a commercial basis.
Device Description Repository Administrator: The DDRA provides an access point to developers to facilitate queries of the Device Repository. The DDRA can configure the access point to route specific queries (or subsets thereof) to specific sources of information.
End-user: The End-User has a device for which a description is available.
Content Provider: The Content Provider has the ability to identify the end-user's device and is able to associate an available device with a description for that device. The description for each device is obtained by merging information obtained from a public device repository with additional information from a private repository.
Repository Provider: The Repository Provider has provided a device repository to the Content Provider that contains a description appropriate to the End-User's device.
Device Description Repository Administrator: The DDRA has configured the Content Provider's Device Description Repository to access information from a default source, except for information relating to menu layouts, which will be obtained from an alternate source.
Content Provider: The Content Provider serves content to the End-User's device that is tailored appropriately for the capabilities of the device. Navigation features of the content are tailored according to the information available in the private repository.
End-user: The End-User consumes tailored content optimized for the capabilities of the End-User's device. Navigation features are optimized for the device.
The End-User launches the browser, navigates available Content Provider services, and then selects a link (URL) that initiates a request for a particular service.
During the request for service the end-user's device provides its identity to the Content Provider;
The Content Provider receives the request for service and the included identity of the device;
Using the identity of the device, the Content Provider obtains the device capabilities from a public available repository;
Using the identity of the device, the Content Provider obtains the optimal menu layouts from a private repository;
The Content Provider utilizes the retrieved device information to tailor the content in a manner best suited for the device, including the choice of menu layout (e.g. linear, hierarchical, animated, popup, softkey etc.).
The Content Provider then serves content to the end-user.
The End-User consumes the served content and receives good user experience
This section is normative.
[DDR-SYS-DDR-QUERY-AVAILABILITY] The DDR MUST provide the ability for stored device descriptions to be queried when required.
[DDR-SYS-DDR-INTERACTION] The DDR MUST provide support for the following interactive capabilities that include.
Informative notifications: Notification of events such as the availability of new device description or device property;
Ordered instructions: The ability to instruct the DDR to perform specific functions, e.g. store new device description, or add new device property to existing device description;
Interrogation: When interrogated DDR must respond with the requested information.
[DDR-SYS-DETERMINATION] The DDR SHOULD provide the ability for an Actors to determine device descriptions according but not limited to the following categories:
Device descriptions that are validated and verified;
Device descriptions that are deprecated;
Different versions of device descriptions for the same device when available;
Device descriptions that fall into one or more categories in order to define device description clustering.
[DDR-SYS-RIGHTS] The DDR MUST provide a rights mechanism that allows an authorized Actor to manage the DDR.
[DDR-SYS-SCALABILITY] The DDR MUST be scalable in nature allowing for the addition of new DDR components.
[DDR-SYS-EXTENSIBILITY] The DDR MUST be extensible in the number of device descriptions and the number of device properties.
[DDR-SYS-AUTHORIZATION] The DDR MUST provide the functionality to enable an authorized Actor to perform the following tasks on the part(s) of the DDR they are authorized to manage:
To load new device descriptions to the DDR;
To load a new version of an existing device description to the DDR;
To load one or more device capabilities to existing device descriptions in the DDR.
[DDR-INT-EXPOSURE] The DDR MUST expose a common high-level interface independently from the programming language or environment chosen to support the management (e.g. add/remove/modify) of available device descriptions.
[DDR-INT-DISCOVERABILITY] The DDR MUST expose an interface that allows an Actor to discover device descriptions and their properties.
[DDR-TECHNOLOGY-REALIZATION] It MUST be possible to realize the DDR and its exposed interfaces through different technologies including but not limited to web services.
[DDR-QRY-DEVICE-IDENTITY] It MUST be possible to query the DDR using appropriate device identity keys that include but are not limited to HTTP headers.
[DDR-QRY-MECHANISMS] The DDR MUST provide the ability for an Actor to query device descriptions using:
An identity key associated with a device for which the query is required;
An expression that may be used to identify a device for which the query is required.
Editorial note | |
The ability to query the DDR based on both device descriptions and device property is for further clarification. |
[DDR-QRY-EXACT] It SHOULD be possible for an Actor to query the DDR specifying an exact match required in response to the query
[DDR-QRY-BEST-EFFORT] It SHOULD be possible for an Actor to query the DDR specifying a best-effort match required in response to the query.
Editorial note | |
Exact and best-effort matches are equivalent in context to strict and loose queries. Definitions explaining Exact match and best-effort will be provided in subsequent versions. |
[DDR-NOT-NOTIFICATION-MATCH] In response to an Actor's query, which includes a quality statement (e.g. the Actor declares if the matching should be exact or best-effort) the DDR SHOULD return a notification indicating its performed match (e.g. the DDR satisfies an exact match or best-effort match).
[DDR-NOT-NOTIFICATION-FAILURE] The DDR MUST support the ability to communicate to a requesting actor when:
The requested device description was not identified;
The requested device description property or properties was not identified;
[DDR-NOT-REASONS] The DDR SHOULD provide the ability to advertise (e.g. through email or other notification methods) to an Actor changes that include but not limited to when:
A new device description is loaded to the DDR;
A new version of an existing device description is loaded to the DDR;
One or more device properties are loaded to existing device descriptions in the DDR.
[DDR-VER-DATA-VERSIONING] The DDR MUST provide the capability to fulfil data versioning, where data includes but is not limited to device descriptions and their device properties.
Editorial note | |
Granularity of versioning will be described in subsequent versions. |
[DDR-VAL-STORAGE] The DDR SHOULD store device description information that is verified, validated and stored accurately. An authorized Actor MUST be able to access information about verification and validation of the data.
[DDR-VAL-DETERMINATION] The DDR MUST support a mechanism to allow an Actor to determine that the existing, new or modified device description information has been verified and validated.
[DDR-VAL-CONFLICTS] The DDR SHOULD be able to resolve conflicts between device description information for the same device that may originate from different sources, e.g. different actors or different compliant DDRs.
Editorial note | |
Definitions explaining verified and validated device descriptions will be provided in subsequent versions. |
This document is the work of the W3C MWI Device Description Working Group .
Members who made significant written contributions to this document include:
Jose Manuel Cantera Fonseca (Telefónica de España, SAU)
Joachim Dahlgren (Drutt Corporation)
Rotan Hanrahan (Mobileaware, Ltd.)
Magnus Lönnroth (Drutt Corporation)
Luca Passani (Openwave Systems Inc.)
James Pearce (Argo Interactive Ltd)
Ove Ranheim (Opera Software)
David Sanders (Vodafone)
Andrea Trasatti (W3C Invited Experts)
Members of the Working Group are (at the time of writing, and in alphabetical order):
Jennifer Bursack (Volantis Systems Ltd)
Bernardo Campillo Soto (Telefónica de España, SAU)
Jose Manuel Cantera Fonseca (Telefónica de España, SAU)
Alberto Cardone (TIM Italia SpA)
Emiliano Ceraldi (TIM Italia SpA)
Yih-Farn Chen (AT&T)
Joachim Dahlgren (Drutt Corporation)
Marcos Eguillor Fernandez (Telefónica de España, SAU)
Rotan Hanrahan (Mobileaware, Ltd.)
Juan Jose Hierro Sureda (Telefónica de España, SAU)
Johan Hjelm (ERICSSON)
Mahesh Kulkarni (Centre for Development of Advanced Computing (CDAC))
Rhys Lewis (Volantis Systems Ltd)
Magnus Lönnroth (Drutt Corporation)
Charles McCathieNevile (Opera Software)
Ram Mohan (Afilias Limited)
Giorgio Natili (International Webmasters Association / HTML Writers Guild (IWA-HWG))
Luca Passani (Openwave Systems Inc.)
James Pearce (Argo Interactive Ltd)
David Puron Carrillo (Telefónica de España, SAU)
Ove Ranheim (Opera Software)
Myungwon Ryu (NeoMtel)
Stefano Sabatini (TIM Italia SpA)
Luciano Sabatino (TIM Italia SpA)
David Sanders (Vodafone)
Andrew Sullivan (Afilias Limited)
Andrea Trasatti (W3C Invited Experts)
Steve Tyler (Royal National Institute for the Blind (RNIB))
Matt Womer (France Telecom)
Seung Chul Yeh (Infraware, Inc.)