Copyright © 2007 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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 Working Group Note 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.
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 Group Note 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 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. Feedback can be directed to the public-ddwg@w3.org, which is a publicly archived mailing list .
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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
1.1 General
1.2 Conventions used in this document
1.3 Scope of Requirements
1.4 Conformance
2 High-level DDR functional requirements
2.1 Fundamentals
2.2 Requirements
3 Use Cases
3.1 Use Case 1: Optimized Web content for mobile devices
3.2 Use Case 2: Querying a Value range
3.3 Use Case 3: Context ambiguity
3.4 Use Case 4: Insufficient context available
This section is informative
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.
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 Device Description Landscape 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.
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.
The DDR must, at a minimum, support:
identification of components of the delivery context
the retrieval of device descriptions
The following are motivated by the use cases:
The DDR MUST expose an API through which device descriptions can be retrieved.
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').
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').
The DDR is expected to follow exception handling requirements as detailed in the DDRAPI document.
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.
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:
It MUST be possible to realize the DDR and its exposed interfaces through different technologies including but not limited to Web services.
This section is informative.
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]
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]
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]
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]