DeviceDescriptionRequirementsArchiveUseCases

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

Use Cases (Informative)

* This section is a non-exhaustive list of likely use cases for a DDR. Any interface and vocabulary steps are references to the DeviceDescriptionsInterface and DeviceDescriptionsVocabulary documents.

This section is informative.

Use-case 1. Utilization of device description information from the DDR

Overview

This use case describes a basic scenario where an end-user consumes web * Web content from their *(mobile) 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.

Actors

End User: The end-user uses their device to consume content or services that they request. The end-user expects a good * a functional user experience when consuming * Web 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 , and utilize that information to provide a good * functional user experience to the End User.

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. * Description Provider: The role taken by a Device Vendor or Device Validator when providing or updating device descriptions to the DDR.

Pre-conditions

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. * The DDR has been populated with accurate device description information by the Description Provider(s).

Post-conditions

End-User: The end-user consumes a tailored service optimized for the capabilities of their device and has a good * a functional 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 ¤ same as pre-condition so removed.

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.

Normal Flow

     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; ¤ what is the scope of identity - unique? generic device?

     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; ¤ refer to interface use case here

     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.

Alternative Flow 1: Device Description not available

     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, either serves default content that is adequate for the range of devices ; e.g. uses other header information from the original request, such as Accept-type, to make a guess at the appropriate content response ¤ replaced this because the original example is not clear

     The user consumes the served content and may not receive the best a functional user experience;

Alternative Flow 2: Capability not identified within a device description

     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 * 3 and 4;

Alternative Flow 3: Utilizing available device description to allow content subscription

¤ Is this an alternative flow? Note sure that a distinction between 'content' and 'content subscription' is significant in this context.

     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;

Alternative Flow 4: Utilizing the device repository for tailoring pushed content

     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.

Use-case 2. Tailoring primary source of content for specific device ranges

Overview

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

Actors

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 * accordingly. in a manner appropriate for the capabilities associated with different ranges of device. The Content Adaptor needs to be confident 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.) ¤ This last sentence is covered in the pre-condition

Pre-conditions

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.

Post-conditions

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. 2.2.5 Normal Flow

     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 a good * functional user experience.

Alternative Flow: Query of device description

     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.

Use-case 3. Availability of a new Device Description

Overview

This use case describes the scenario where a Device Vendor or other appropriate actors such as an open-source Framework Provider * Description 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.

Actors

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.

Pre-conditions

Device Vendor: The Device Vendor * Description Provider: The Description Provider 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).

Post-conditions

Device Vendor: The Device Vendor * Description Provider: The Description Provider 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. 2.3.5 Normal Flow

     A Device Vendor * Description Provider 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.

Alternative Flow 1: Replacement of existing device description

     The Device Vendor * Description Provider 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 * Description Provider 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.

Alternative Flow 2: Modification and updating of existing device description

     Same as Alternative flow 1 step 1;

     The Device Vendor * Description Provider 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 * Description Provider updates the existing device repository indicating support for the new MIME type;

     Same as Alternative flow 1 steps 3 and 4

Use-case 4. Device Repository query capability

¤ This will defer to the interface document where necessary.

2.4.1 Overview

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.

Actors

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.

Pre-conditions

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.

Post-conditions

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.

Normal Flow

     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 XHTML-MP) to the Content Adaptor;

     The Content Adaptor receives and utilizes the results for their own purpose.

Use-case 5. Using device descriptions from both a public and a private repository

Overview

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.

Actors

End User: The End-User uses a device to consume content or services requested from the Content Provider. A good functional 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.

Pre-conditions

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.

Post-conditions

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.

Normal Flow

     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

¤ Todo: normalise the Actors/pre- post- conditions to ensure consistency and brevity