From Device Description Working Group Wiki
This is the Review of Current Technologies section of the document. See the DeviceDescriptionLandscape overview.
Review of current technologies
In order to reflect the state of Device Description and content adaptation technologies the MWI issued a public questionnaire [DD-Survey]. The results of this questionnaire combined with the feedback from the MWI membership and the public DDWG mailing list have been used as the basis for this section.
All identifying information from the questionnaire has been removed prior to being included here.
The questionnaire was published in August of 2005, and received 17 results at the time of the writing of this draft. It contains 13 questions specifically about the collection, storage, and usage of Device Descriptions.
The questionnaire was designed to establish how Device Descriptions are being created and consumed, and to identify the scope of the way in which they are being used.
Amongst the respondents were browser developers, content adaptation solution providers, and other standards bodies. 12 of the 17 responses were from content adaptation providers, and thus this section is biased towards content adaptors.
In this section, we review the findings of the questionnaire.
The results of the survey indicate that the majority of content adaptation and Device Description solutions:
- are relevant to a wide variety of markup languages, the most common being HTML and WML variations
- provide or consume extensible Device Description vocabularies
- provide or consume Device Descriptions either programmatically or through database queries
- use the OMA UAProf standard in some fashion; for example to seed the description database
- provide a vocabulary for device attributes
- utilize XML for storage or transmission of Device Descriptions in some capacity
- are relevant to mobile devices with text and graphic screens, with touch screen, keyboard, and joystick inputs
All responders expressing an opinion believe that device descriptions should be publicly available in some form, representing an appreciation of the importance of their role in assisting the success of the mobile web.
The data models used for Device Descriptions, according to respondents, vary from simple flat XML files with no inheritance to full relational databases.
A number of the data models used include a way to inherit from another Device Description. For example, if a new device is introduced that is similar to an existing device, a Device Description may only include the information that is different between the two, and rely on a logical reference to the description of the existing device to complete the description. UAProfile and CC/PP both provide a defaults mechanism that could be viewed as a limited form of inheritance.
Other data models described are more complex and include concepts similar to multiple inheritance, where a Device Description may extend other descriptions, or abstract classes of generic device.
Similar to inheritance is the technique of 'fallback', which is particularly relevant during the device recognition process prior to content adaptation. Fallback allows the matching of an unknown device with a 'best fit' device description. This allows for new devices that do not have a description available to still be used. For example, if an unknown device's manufacturer can at least be determined from say, the user-agent, it may be possible to utilize Device Description attributes which are known to be common to all of that manufacturer's devices.
Respondent's opinions vary on the techniques of fallback and inheritance. The more complex data models that makes use of inheritance and fallback result in a smaller Device Description repositories, as redundant descriptions are 'factored out'. On the other hand, a simpler data model without inheritance can help avoid quality control issues that can occur in a complex data model. For example, when inheritance is used, a change in a base device description may adversely effect multiple Device Descriptions, perhaps unintentionally.
The questionnaire included a question about the number of properties required for acceptable adaptation. From the responses, it is believed that acceptable adaptation can be achieved through a relatively small number of device properties, although radically different attributes are valuable in particular content adaptation contexts, or for particular applications.
(As a simple example, the attributes needed by a mobile photo download site would mostly refer to the devices' abilities to support graphics formats, whereas a text-based news site might rather benefit from attributes concerning page size and navigation behavior.)
In any case, certain properties are absolutely required, and are critical for the author or adaptor, while a larger number of properties are required to perform more accurate adaptation. The presence of hundreds to thousands of properties in some of the surveyed solutions indicates that further properties are needed for complex tasks, or where a range of different applications or contexts are being serviced.
Essential device attributes
As a result of this questionnaire, the DDWG conducted a follow-up member poll, to develop a list of 'core attributes', that are deemed essential for content adaptation. While some of these items represent relatively broad functionality of mobile devices, and aren't yet necessarily defined unambiguously, this list does serve to illustrate the areas of diversity in mobile devices that cause challenges when developing for the mobile web.
The following sections describe these attributes and property groups in more detail.
As it is generally the primary output paradigm for a mobile devices, knowledge about the characteristics of the screen were deemed to be essential for content adaptation. Screen size is important since it constrains the amount of web content that can be displayed at one time.
It is also important because devices exhibit a range of ways in which content that exceeds the screen size is rendered and navigated, including image rescaling, cropping, text wrapping, truncation and auto-scrolling. An understanding of the screen size itself reduces the need to understand the subtleties of these complex behaviors in a given device.
At the same time, it should be appreciated that there are many ways of defining screen dimensions. Which units of measure are required (pixels, centimeters, etc) and which object measure is required for (physical screen(s), browser canvas, scrollable view-port, etc) will vary depending on many contextual factors.
Supported & preferred markup
Since a major branching point in many content adaptation processes is the choice of which markup to provide to a device, a rich understanding of what content it supports and prefers is essential for those processes.
Many mobile devices are capable of displaying only one type of markup. However, others support multiple web (and legacy) markups, often interchangeably. In addition, many devices are lax at parsing markup and can often perform surprisingly well at rendering types for which they do not claim support.
All of these factors drive the need for attributes to capture this behavior. Required knowledge certainly includes which markup is most preferred, but also which are claimed to be supported - and how they correlates to the 'accepted' MIME-types in the device's requests.
Supported & preferred image formats
In a similar way to markup, devices support and prefer a range of different image formats. and knowledge about this behavior is essential for content adaptation of any rich content.
Describing image support is also a relatively complex task, since most major image formats have optional features or variants that a device may or may not separately support. Image support also needs to be correlated with the 'accepted' MIME-types in the device's request. However, at the very least, knowing which major formats are supported is essential.
As most mobile devices are of limited dimension and form-factor, the memory constraints of the device's software are often significant when delivering mobile web content to them.
In particular, the maximum page markup size, image size, and overall page weight are device attributes that are of value to a content adaptation process.
Detailed knowledge about these behaviors may become less necessary in the future as device memory sizes inexorably rise.
Whether a device supports color content, to what color-depth, and how it behaves when the content's color-depth is higher (dithering or grey-scaling, for example) is value knowledge for a content adaptation system.
However, many modern mobile devices now support color well, and over time, it is likely that these attributes decrease in value.
Other browser features
There are many mobile web markup features, rendering behaviors, and auxiliary techniques that certain devices support well, whilst others do not. It is clear that some degree of knowledge for these subtleties of browser behavior is required in a Device Description.
Examples provided include table support (including maximum column and row sizes, support for merged cells, and so on), multi-part-MIME support (for amalgamated page delivery), and Digital Rights Management adherence.
Reference was also made by respondents to general browser faults or bugs. It is valuable for a content adaptation system to be aware of unsatisfactory behavior of device browsers under certain conditions, so that those conditions can be avoided.
Non-markup object support
Finally, in responses to this poll, many attached value to understanding device support for non-markup objects that are either embedded in a page or linked to from a page.
These types include video (both embedded and streamed), J2ME (or other applications) ringtones, and other audio types.
While some of these can be deemed to be beyond the scope of the mobile web per se, it should be appreciated that these types of content are popular amongst mobile device users. It is for the download of video clips, ringtones, and games to their devices that many users will interact with mobile web technologies at all.
All of the content adaptation technologies surveyed provide a mechanism for extending the Device Description. There is a wide appreciation that the areas of diversity between mobile devices is a moving target and that any technology that describes devices needs to be adaptable and extensible. Similarly, it is essential that a Device Description repository itself be extensible in order to accommodate new devices, device attributes, and use cases.
When discussing a publicly available shared Device Description repository, extensibility is even more relevant, as a public repository may be used in any number of ways, and should be as accommodating as possible.
All of the content adaptation technologies surveyed allow for querying the Device Descriptions, either through a programmatic interface or via database queries.
There are a number of ways in which queries are used. Obviously, it is essential that the Device Descriptions be available at adaptation time. It is also important that authors be able to query descriptions at design-time in order to determine which properties may be available and what general trends of device support exist. The Device Description repository may also be queried for statistical or analytical usage, such as determining the number of devices that support a particular markup language.