The MWI-DDWG is charterted to the simplification and standardization of issues around device description for content adaptation. In this scenario one specific problem that arise is the definition of portable mechanisms for defining groups of devices that share common characteristics. This Note is devoted to different technical approaches for solving this problem. Additionally, it is defined an standard API that can be used in the development of applications that exploit device structure information for adaptation or other purposes.
This is
Publication as
This document is published as part of the W3C
Please send comments to
This document was produced by a group operating under the
First draft
JMCF: To be revised
The mobile handset market is very innovative and dynamic, offering tons of devices made by different manufacturers. However, it is noteworthy that most of these devices share common characteristics, and, as a result, there is a tendency towards device grouping into families to capture sets of devices that share common characteristics. Two specific examples, are the 'Nokia Series 60' family or the 'Smartphone devices'. Device grouping is useful as it provides a level of abstraction (in an specific context) that avoids in thinking on specific models or particularities.
Device grouping is not only useful for abstraction purposes. There also different situations regarding adaptation of content in the mobile web where it is needed to group different kind of devices to create categories, families, hierarchies or clusters of devices. For example, "The customer wants to include an extra link in a page for those devices that belong to the Nokia Series 60" family. This kind of functionality is currently available in different content adaptation solutions in the commercial and open source space. The problem with the existing approaches is that none of them is standardized and, as a result, it is not feasible to share families of devices between different device description repositories. Therefore, it would be desirable to define standard mechanisms and APIs that enable the definition of portable mechanisms for grouping devices.
This W3C Note describes the situations where device grouping is useful and proposes techniques, formalisms and extended DDR-APIs for solving in a standard way the problem of device grouping.
Delivery Context Ontology
DDR-API
This specification provides a definition of an interface based on OMG IDL
In addition, it also provides a WSDL
review
Examples given in this specification are informational. The programming language used in examples are Java and PHP.
John is a developer in charge of designing and deploying a new mobile web site. As a requirement the site must be accesible from a myriad of devices including mobile phones, smartphones and different kind of PDAs (Palm, Blackberry, Pocket PC). The customer is expecting a good experience in all the devices addressed, exploiting all device features at a maximum.
There are some requirements that has to do with the presentation of different information in tabular format. Initially John starts designing all the tables to have only two columns, restricting the amount of information of each entity to the two most important data fields. This design is suitable for the majority of mobile phones but when he tests on a PDA device, John realizes that two columns provide a very poor result on a PDA device. He realizes that space is wasted and decides to add an additional column that will be only displayed for those devices that are PDAs.
To overcome that issue, John creates a new device family called 'PDADevice' using a tool provided by a W3C-compliant device description solution. This family of devices will be characterized by a set conditions on the device capabilities, such as screen dimensions, supported markup code, available memory, etc. Once the device family is created and uploaded to the DDR, John uses the DDR API in his favourite programming language to generate the markup table accordingly to the established requirements.
Company A wants to develop a new mobile web application and would like to provide different layout and content to different groups of devices. As company A doesn't like reinventing the wheel, instead of creating a new device family, queries the DDR, and realizes that there is a device family that suits its needs as defined by company B who is working in the same space. Company A can consistently reuse that family of devices and references it in his own application.
It is common to hear names such as "Smartphone", "Musicphone", "Featurephone", but does anyone know what they mean in detail? Is a Smartphone a device to make calls, synchronize your calendar and provide a fully featured address book? If so, what is the difference between a Smartphone and a PDA? When does a mobile phone "turn" into a Smartphone? When isn't it a Smartphone anymore and become a PDA?
All these definitions are very important to many individuals and companies. Providing a way to define clearly {*} and formally what they are will help comunication between different individuals and companies.
When developing an application, for J2ME, Symbian etc, it is often useful to create different builds for different devices or use different API's to exploit the device capabilities, namely 3D hardware acceleration, stereo speakers, bluetooth chips, GPS support and more. In order to do this, developers might have to create one build for each device on the market. Many devices actually share the same functionalities and support the same API's. Developing and testing on a device often means supporting a range of devices. Companies in this space will claim compatibility with device families instead of individual devices.
An specific instantiation of this use case, relevant to the Mobile Web, is a mobile web browser vendor who wants to express the fact that their browser works in a set of devices. For example, "our MiniBrowser is compatible with all Nokia Series 60 devices".
Company A is a developer of J2ME applications. Every month its QA team tests the new games against the devices they have in their lab. Devices used for testing are often considered master devices representing a number of other devices that will not be tested directly. Also, every month, the company lab buys new devices, old games are tested against these devices for compatibility. Company A states formally on which devices and device families their games work on.
Company B is a content aggregator. Every month receives from different software developers a number of new games. Company B also keeps updates of their device database so every month new devices are added. Every month Company A sends to Company B a list of the games and a list of the devices and group of devices (families) compatible with the games provided.
Company B needs to go back and check the list of devices and games every month for each of the games. The ability of using a common representation of device families between Company B and each of its affiliate games developers would ease the work on a daily basis and make sure that all the devices that are certified to work with a certain game are up-to-date. For example, if Company B has a brand new device in its database and that device belongs to a device family certified by Company A, Company B can automatically state that a certain game works in that new device.
The most easy way to create device families is to use boolean expressions that denote the conditions that a device must satisfy in order to belong to an specific family or cluster of devices. The formal syntax for defining that kind of expressions is (in simple Extended Backus-Naur Form (EBNF) notation):
.
This appendix contains the complete OMG IDL
tbd
This section is informative. It provides an illustration of how the DDR-API could operate.
The editor of the document acknowledge significant written contributions coming from: