Device Description Repository 1.0

1.1 Scope

The W3C DDR API offers various levels of functionality to satisfy differing Use Cases [q.v.]. The classification of the various levels relates to conformance claims [q.v.]. The DDR Basic Interface provides read-only functionality to allow an adapting application to identify the Delivery Context (DC) and to query the DDR for attribute values for components of the DC.

In addition, it provides access to basic catalog information that allows it to find out about which attributes are supported and what devices and models are supported. Advanced functions allow the addition of information to the DDR and provide more elaborate access to the Cataloguing functions.

Many aspects of the operation of a real world DDR are not standardised by this recommendation, for example, user management, user identification and authentication, management of the data within the DDR. The recommendation makes no assumptions about the internals of the DDR, the physical storage mechanism, the distribution across actual servers and so on. In addition, the details of the operation of the API are not specified - e.g. how to instantiate and close the library, concurrency and threading and whether the calls are blocking or non-blocking.

1.2 Uses for the DDR-API

The DDR-API can be used in any scenario that implies the necessity of accessing device descriptions. The DDR-API is not bound to any particular kind of device description or property.

However, it is noteworthy to point that one of the key uses for DDR-API are related to content adaptation for device independence. Materials to be used on a particular device may need to be tailored to take account of that device's particular capabilities. Layout, styling and the media associated with a web page may all need to be tailored based on the delivery context to achieve a good user experience.

1.3 Reading the Specification

2.1 CC/PP

CC/PP is an RDF framework for defining vocabularies for capabilities of mobile devices

2.2 DCCI

DCCI is the standard API that allow to retrieve delivery context properties from the client side. The capabilities made accesible through DCCI are very dynamic in nature.

2.3 DPE

DPE is a framework for retrieving device capabilities that can change during the lifetime of a user session

2.4 Delivery Context Ontology

The Delivery Context Ontology is an ontology that captures all the knowledge behind the delivery context.

4.1 Documentation Conventions

4.2 Naming Conventions

This specification provides a normative definition of the interface based on OMG IDL [IDL].

In addition, it also provides a normative WSDL [WSDL] binding.

4.3 Examples

Examples given in this specification are informational. The programming language used in examples are Java and PHP.

5.1 Introduction

The DDR-API separates in different modules and functions the process of identification of the delivery context from the process of retrieving device properties. As a result the concepts of context key and context key handler are introduced.

5.2 Context Key

5.3 Context Key Handler

6.1 Introduction

This section is informative.

The delivery context models the environment into which content is to be delivered. For Web Browsing, it includes, but is not limited to, network connections, gateways, proxies and a device running a browser (possibly with addtional helper applications). The device may have additional hardware attached, such as an external keyboard, display monitor, speech generation and assistive technologies such as a screen reader. Each identifiable item is called a "component of the Delivery Context", or component, for short.

Each component of an actual delivery context has a type. The DDR API does not prescribe which components any given DDR implementation may choose to recognise, nor does it prescribe the precise definition of any particular component type. For example, any DDR implementation may choose to model the DC in any way - a conforming DDR must, however, implement components that support the attributes identified by the [version of the] Core Vocabulary in some components. Typically, it is understood that most DDRs will share a similar view of the Component Types of Device Hardware and Browser.

6.2 Common Datatypes

6.3 Additional Types

6.4 Property Collections

6.5 Metadata

7.1 Core Interfaces

7.2 Querying and Searching

7.3 The DDRException Exception

DDR-API defines one specific additional exception, named DDR-APIException, in addition to those that can defined by the DOM itself.

exception DDRException {
   unsigned short code;
};
//Exception codes
const unsigned short ACCESS_VIOLATION_ERROR = 1;
const unsigned short NOT_SUPPORTED_ERROR    = 2;
const unsigned short PROPERTY_FILTER_ERROR  = 3;

7.4 Errors

In general, DDR-API operations return values that may indicate error conditions. In "exceptional" circumstances, DDR-API operations may raise exceptions, for example, when an operation is impossible to perform.

7.5 Extended Interfaces

8.1 Extending Device Descriptions and Properties

9.1 Conformance Requirements for DDR-API Implementations

A conforming DDR-API implementation must implement all the normative sections of this document.

A conforming DDR-API implementation

10.1 DDR-API Exception Interface