DeviceDescriptionRequirementsArchiveHighLevelRequirements

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

High-level DDR functional requirements

This section is normative.

* The high-level requirements can be categorized as either Data, Usage or Administration.

* Data pertains to the data model requirements of the repository * and any system which supports it.

* Usage pertains to the functional requirements available to those Actors who consume the device description properties (hereafter referred to as 'consumers').

* Administration pertains to the deployment, management and operation requirements of the repository.

Data requirements

[DDR-DATA-STORAGE]

* The DDR MUST provide a persistent store of device descriptions conformant to the requirements below. ¤ device description will link to DIG

[DDR-DATA-SCOPE]

* The DDR MUST only store static properties. Dynamic properties (i.e. those that can change over time) MUST NOT be stored.

* DDR MUST only store static device characteristics (i.e. property values inherent to every instance of a device that do not change over time, error correction not withstanding), and not dynamic (i.e. property values mutable over time) ¤ suggest we need a link to a standard definition for static and dynamic property when available.

[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. ¤ requirement reintroduced following F2F

[DDR-DATA-MODEL]

* The syntax of, and relationship between, device properties stored in the DDR MUST conform to the DDWG CoreVocabulary.

[DDR-DATA-QUALITY]

¤ original version: 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. ¤ first revision: The DDR MUST store the originating source of each property value and any assertions as to its validity, and allow authorized Actors access to this information. The same applies to any subsequent versions of the property value. * The DDR MUST be able to establish, and subsequently convey to authorized Actors, information about the origin of property values and any assertions about their validity. * This information SHOULD allow the requesting Actor to determine if they can trust the quality of the data. * In the event that the origin of a property value is unknown it MUST be indicated as such.

[DDR-DATA-DEVICE-KEY]

* The DDR data model MUST allow a lookup from a device identifier to the associated device property values; and from a device property value * or value range to its associated devices. * This lookup MUST be through means of a compound key comprised of identifiers of both the hardware and the parts of the software which are relevant to Web consumption (for example, Web browser and firmware identifiers). If software identifiers are not available then the DDR will assume the default 'out of the box' software for the indicated hardware. ¤ needs to be rephrased following key discussions.

EDITOR NOTE: Do we know yet what the device identifier/s are? UA, TAC etc.? Will the Core Vocabulary cover this?

[DDR-SYSTEM-SCALABILITY]

The DDR MUST be scalable in nature allowing for the addition of new DDR components. The DDR MUST be extensible scalable in the number of device descriptions and the number of device properties.

[DDR-SYSTEM-EXTENSIBILITY]

The DDR MUST be scalable in nature allowing for the addition of new DDR components. * It is RECOMMENDED that the DDR system supports an extensiblity mechanism to support any future components. ¤ swapped extensibility and scalability defintions.

[DDR-SYSTEM-TECHNOLOGY]

It MUST be possible to realize the DDR and its exposed interfaces through different technologies including but not limited to web services. * The implementor is free to choose the technology (DBMS, XML database, LDAP etc.) and methodology (Relational, Dimensional, etc.) used to implement these requirements.

Usage requirements

[DDR-USE-INTERFACE]

[DDR-INT-DISCOVERABILITY] The DDR MUST expose an interface that allows an Actor to discover device descriptions and their properties. * The DDR MUST expose an interface for consumers to discover and retrieve device properties. This interface MUST conform to the DeviceDescriptionRepositoryApi requirements.

[DDR-USE-QUERY]

It MUST be possible for an authorised consumer to query the DDR to retrieve a device description, * as detailed in the DeviceDescriptionRepositoryApi requirements . It MUST be possible for the consumer to define the scope of this description, namely the device property value or values which he wishes to retrieve.

[DDR-USE-QUALITY-VERIFICATION]

[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. 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. ¤ The repository contribution to this is covered in DDR-DATA-QUALITY and SOURCE requirements, whereas this requirement is better placed as an API requirement.

Administration requirements

[DDR-ADMIN-DATA-PROVISIONING]

[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. * It MUST be possible for an administrator to provision new devices, device properties, and device property values to the repository.

* It MAY be possible to provision the DDR through the ingestion of other device description vocabularies (e.g. an existing UAProf definition). It is the responsibility of the implementor to map these imported properties to their equivalent DDR property.

[DDR-ADMIN-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. * The DDR MUST support versioning, either inherently or via another system, of device descriptions * both device descriptions and individual device properties.

[DDR-ADMIN-DATA-CONCURRENCY]

* It MUST be possible to store multiple concurrent versions of a property value, whereby each version is sourced from a different origin. It MUST be possible to relate a particular value of a given property with an identifier of its origin.

[DDR-ADMIN-DATA-ROLLBACK]

* The DDR MUST be able to rollback to previous versions of a the full repository or a subset thereof (e.g., rollback a single property or device description).

[DDR-ADMIN-DATA-MANAGEMENT]

It MUST be possible for an administrator * or sufficiently privileged user to update or delete an existing device property.

* Referential integrity MUST be maintained: i.e., on deletion of a device from the DDR the associated device property values for that device MUST also be deleted.

[DDR-ADMIN-RIGHTS]

The DDR * It MUST provide a rights mechanism that allows * be possible to enable an authorized Actor * or Actors to manage the DDR as per the [DDR-ADMIN] requirements listed below.

[DDR-ADMIN-ACCESS]

* The implementor MAY apply a user authentication step for public access, and it is RECOMMENDED to do so for any premium access.

[DDR-ADMIN-AVAILABILITY]

* The implementor SHOULD ensure that high availability (uptime) is maintained.

[DDR-ADMIN-MIRRORING]

* The implementor MAY make the entire repository, or a section therof, available for mirroring/replication.

[DDR-ADMIN-NOTIFICATION]

The DDR SHOULD provide the ability to advertise (e.g. through email or other notification methods) to an Actor events that include, but are not limited to:

1. A new device description loaded to the DDR;
2. An existing DDR device description has been changed or deleted;
3. One or more device properties are loaded to existing device descriptions in the DDR.

Ed note: the following requirements indicate API functionality and as such should be covered by the API document, as referenced by [DDR-USE-INTERFACE]

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

1. Informative notifications: Notification of events such as the availability of new device description or device property; 2. 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; 3. Interrogation: When interrogated DDR must respond with the requested information.

[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:

1. An identity key associated with a device for which the query is required; 2. An expression that may be used to identify a device for which the query is required.

[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-SYS-DETERMINATION] The DDR SHOULD provide the ability for an Actors to determine device descriptions according but not limited to the following categories:

1. Device descriptions that are validated and verified;
2. Device descriptions that are deprecated;
3. Different versions of device descriptions for the same device when available;
4. Device descriptions that fall into one or more categories in order to define device description clustering.

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

...end of Ed note

Ed note: the following requirements have been moved to the Admin and Data sections as appropriate

==== System Requirements ==== [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:

1. To load new device descriptions to the DDR; 2. To load a new version of an existing device description to the DDR; 3. To load one or more device capabilities to existing device descriptions in the DDR.

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

Ed note: This section is also API-centric and hence is referenced in DDR-USE-QUERY

==== Interface requirements ====

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

...end of Ed Note

ToDo: rename the requirements according to the new section headings</b>