Device Description Repository Requirements - Criteria for judging the quality of a DDR implementation (Work in progress)

This is a merger of all of the Wiki pages in order to approximate the final document.

---

This is the Preamble to the document. See the DeviceDescriptionRequirements overview.

Abstract

This W3C Working Draft specifies the behavior expected of a repository for device descriptions. The scope of the requirements covers the retrieval of device descriptions from such a repository; and any API requirements needed to support such behaviours.

* This document details use cases for a Device Descriptions Repository (DDR). In order to realize these use cases, certain behaviors will be expected of a DDR: these behaviors are determined and listed as requirements.__

This document forms one of the deliverables of the W3C Mobile Web Initiative Device Description Working Group. The requirements in this document are derived from the listed use-cases as well as information in the Device Description Landscape DDLAND and Device Description Ecosystem DDECO documents.

Status of this Document

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/.

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 is a First Public Working Draft of a future Working Group Note. It 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. This Working Group is part of the Mobile Web Initiative. 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.

---

---

This is the Introduction section of the document. See the DeviceDescriptionRepositoryRequirements overview.

Introduction

This section is informative

General

* This document describes the use cases for a Device Description Repository (DDR). Each use case is analyzed in order to determine the behavior expected of a DDR in order to realize it. These expected behaviors are captured as high-level requirements, which when normalized across all use cases, lead to a discrete set of DDR requirements.

* Such a repository A DDR forms part of the Scope and Deliverables of the MWI Device Descriptions Working Group (DDWG) Charter, based on the motivations described in the DeviceDescriptionLandscape document.

Conventions used in this document

* The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119

Scope of requirements

The requirements in this document cover the behaviors expected of a Device Descriptions Repository. The requirements are at a high-level and, with the exception of [DDR-TECHNOLOGY], do not prescribe or recommend a particular technology solution. * For the same reason the implementation, data provisioning, security and operation of a DDR are not in scope of this document.

* The Scope of the requirements is bound by the scope of the DDWG Charter, specifically Identification of device characteristics ... that enhance the user experience of Web browsing, while mobile.

Conformance

* A Device Description Repository will be DDWG DDR conformant if it meets all the mandatory requirements stated in the High level requirements section of this document. Any other optional DDWG DDR requirements, and non-DDWG functions, may also be implemented.

This is the High-level DDR functional requirements of the document. See the DeviceDescriptionRepositoryRequirements overview.

High-level DDR functional requirements

Fundamentals

* The DDR API must, at a minimum, support

1. identification of components of the delivery context
2. the retrieval of device descriptions

Requirements

The following are motivated by the use cases:

[DDR API] The DDR MUST expose an API through which device descriptions can be retrieved.

[DDR-MEASUREMENT] If a value returned by the DDR is an indication of measurement (such as width or resolution) then the units of measurement are expected to be unambiguous to the requesting party: i.e. either the vlaue returned explicitly declares the measurement unit, or the requesting party specifically asked for the value in a particular unit ('screen width in cm').

[DDR-CONTEXT-KEY] The DDR is expected to attempt to return a device description (or element thereof) based on identification of the hardware and/or software that the description relates to (the 'context key').

[DDR-INSUFFICIENT-CONTEXT-EXCEPTION] The DDR is expected to follow exception handling requirements as detailed in the DDRAPI document.

[DDR-VALUE-RANGE] The DDR is expected to return a range of all known values of a particular device capability for a given context key if requested to do so.

[DDR-CONTEXT-AMBIGUITY] Should the DDR not receive enough information to accurately determine the context key, then it is expected to either (a) make a 'best effort' guess based on the evidence available, (b) return all possible values for the aspects of the description queried, or (c) return an exception as detailed in the DDR-API document

The following requirement is a goal of the DDWG:

[DDR-TECHNOLOGY] It MUST be possible to realize the DDR and its exposed interfaces through different technologies including but not limited to Web services.

This is the Use Cases section of the document. See the DeviceDescriptionRepositoryRequirements overview.

This section is informative.

Use-case 1. Optimized Web content for mobile devices

Bruce is a Web content author who wishes to provide an optimized user experience for those users accessing his site via a mobile device. Using standard HTTP request headers, he is able to recognise the mobile handset and browser software making the request. He queries a DDR using the handset and browser as query criteria, and asks for the width of the handset screen in pixels. The DDR uses the query criteria to identify the device used, and returns the screen width in pixels, accordingly.

Motivates: [DDR-API], [DDR-CONTEXT-KEY], [DDR-MEASUREMENT]

Use-case 2. Querying a Value range

Hal is also a Web content author who queries a DDR for information that will improve mobile users' browsing experience. He wishes to know all the image formats supported by a particular device/browser combination. As such he queries the DDR, passing in a device/browser identifier. The DDR uses this information to return all the image formats supported in this case.

Motivates: [DDR API], [DDR-CONTEXT-KEY], [DDR-VALUE-RANGE]

Use-case 3. Context ambiguity

Carter wishes to determine the markup formats supported by a mobile device that has requested his Web page. He queries a DDR for this information, but only passes in a device hardware identifier, without an indication of the browser used. As such the DDR makes a 'best effort' guess that the browser is the one that comes pre-installed on that device, and returns a range of supported markups for that browser accordingly. Note: where context is ambiguous, the DDR may instead choose to throw an exception, or return all possible values based on the available evidence: it is likely that different aspects will determine different behaviour.

Motivates: [DDR-CONTEXT-AMBIGUITY]

Use-case 3. Insufficient context available

Diana wishes to determine the screen resolution in pixels of the device querying her Web page. However she is only able to determine the browser, but not the device hardware, making the request. When queried, the DDR is unble to resolve the context key of the request and throws an exception.

Motivates: [DDR-INSUFFICIENT-CONTEXT-EXCEPTION]

This is the References section of the document. See the DeviceDescriptionRepositoryRequirements overview.

References (Non-Normative)

DDECO

   Device Description Ecosystem, World Wide Web Consortium, 21 November 2005. Editor: R Hanrahan (MobileAware). The latest version is at http://www.w3.org/TR/2005/WD-dd-ecosystem/. (See http://www.w3.org/TR/2005/WD-dd-ecosystem-20051121/.)

DDLAND

   Device Description Landscape, World Wide Web Consortium, 10 February 2006. Editors: J Pearce (Argogroup), M Womer (France Telecom). The latest version is at http://www.w3.org/TR/dd-landscape/. (See http://www.w3.org/TR/2006/WD-dd-landscape-20060210/.)

DIG

   Glossary of Terms for Device Independence, World Wide Web Consortium, 18 January 2006. Editor: Rhys Lewis (Volantis Systems). The latest version is at http://www.w3.org/TR/di-gloss/. (See http://www.w3.org/TR/2005/WD-di-gloss-20050118/.) 

This is the Acknowledgements section of the document. See the DeviceDescriptionRepositoryRequirements overview.

A Acknowledgements (Non-Normative)

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.)