W3C home > Mailing lists > Public > public-ddwg@w3.org > August 2005

[wbs] Rotan Hanrahan response to 'Device Description Technologies Survey'

From: WBS Mailer on behalf of <webmaster@w3.org>
Date: Fri, 12 Aug 2005 14:10:02 +0000
To: rotan.hanrahan@mobileaware.com,member-ddwg@w3.org,public-ddwg@w3.org
Message-Id: <wbs-053939cf75781d33317be5b721e56bb9@cgi.w3.org>

Here are the answers submitted to 'Device Description Technologies Survey'
(the public) for Rotan Hanrahan.

Name of device description technology or device description product

MobileAware Device Repository (MDR)

Status of technology 
For example, indicate whether the technology is an open standard, a
reference implementation or a proprietary technology.

Proprietary technology.

Context of the technology 
Is the technology or product used for content adaptation? If not, what is
its purpose? What is the target audience? Is it a standalone technology,
or is it part of another product or platform?

The MDR is a key component of MobileAware’s Mobile Interaction Server
(MIS) and related products that adapt XHTML based content for a wide
variety of mobile and fixed browsers. It is typically deployed with
telecommunications operators and enterprise organisations. The MDR is used
as part of the device recognition process, and then subsequently to provide
device characteristics and appropriate usage parameters. It is possible to
integrate the MDR with other products but is normally deployed as part of
a complete MobileAware solution.

What markup languages does your product support? 

 * [x] WML 1.x (WML)
 * [x] WML 2.x (XHTML-MP)
 * [x] iMode/cHTML
 * [x] HTML (3.2 up)
 * [x] XHTML
 * [ ] VoiceXml
 * [x] Other W3C Markup (e.g. SVG, SMIL) (Fill the text area below)
 * [x] Other non-W3C Markup (Newsml, ...) (Fill the text area below)
 * [x] Proprietary content (Fill the text area below)

The MDR records all of the data types supported by the devices. The markup
languages listed above are representative of the target languages that the
MobileAware transformation process can generate, based on information from
the MDR. The transformation process can also generate normal text and
(through various custom connectors) arbitrary XML formats.

What are input and output features supported by your product ?

 * [x] Touch screen (phone, PDA, "full" size)
 * [x] Limited keys
 * [x] Joystick/mouse (continuous pointer) 
 * [x] Full keyboard (on-screen, detachable, permanent)
 * [ ] Voice
 * [x] Other (gravity sensor, barcode, etc - please explain) (Fill the
text area below)

Input from specialised devices can be relayed to custom information


 * [x] Text screen
 * [x] Graphic screen (tiny, small, medium, large)
 * [ ] Multi screens
 * [ ] "heads-up screen"
 * [ ] Voice
 * [x] Other (Fill the text area below)

MobileAware products can also deliver appropriate audio resources to
audio-enabled devices and adapt images to the rendering capabilities of
any primary display surface associated with the target browser.

If you can, please provide a brief architectural overview of the
technology or product.

The MDR can be deployed as a Relational DB or as a clustered data object.
It can also be expressed in XML. During operation, the MDR is queried by
device recognition processes to identify the target device and other
delivery context information. This data is used by the transformation
processes as part of the response chain to ensure appropriately adapted
content is delivered to the requesting device. The MDR is regularly
updated by MobileAware.

Reliance or usage of existing standards 
Please indicate how the device-description part of your technology or
product builds (or relies upon) existing standards. For example: HTTP,
XML, CC/PP, etc

Products employing the MDR are predominantly developed in Java (EE). The
MDR permits access via CC/PP and UAProf (JSR 188), through DB queries and
through custom accessors. The vocabularies are extended to support
information not currently present in standard repositories. Authored
content intended for adaptation is based on XHTML and generated by the
server using appropriate Java (EE) technologies. The administrator can
customise/extend the data in the MDR. Services implemented on a
MobileAware-based solution can also directly access the MDR to use
contextual information as part of the service processes.

Does the technology specify, or provide, a repository (or repositories)
for the storage of the device descriptions?
if you answer "yes", provide the following details:

         * a brief description of the data structure
        e.g. flat files, RDMBS, OODMS, hierarchical data structures
         * To what level of abstraction does the repository store the
        e.g. per model, per operator, per browser etc
         * How does the technology manage multiple revisions of the same
        (e.g. inheritance, fallback, etc)
         * How does the technology manage attributes or properties for
unknown devices?
        (i.e. those not yet stored or those not recognised)

         * In
your experience, how many discrete device descriptions do you believe
are essential to produce satisfactory content adaptation worldwide? 
            - < 10
            - 10 - 50
            - 50 - 100
            - 100 - 200
            - > 200


 * (x) Yes
 * ( ) No

Comments (or a URI pointing to your comments): 
The MDR can be expressed as XML or as a relational DB. It is not a flat
structure, but uses hierarchies and relationships to reflect the reality
of devices in the market. Information in the MDR is highly specific for
individual devices. The MDR can represent more abstract properties
associated with collections of devices, typically based on manufacturer or
browser type. Inheritance is the natural means of addressing multiple
revisions of the same device, which is part of the multi-dimensional
recognition strategy employed by the MDR to identify devices, including
those that are unknown but which bear some similarities or common heritage
with existing devices. MobileAware observes that globally the number of
discrete devices needed to be supported by a device description solution
far exceeds the upper figure of 200 in the questionnaire.

Does the technology specify an explicit vocabulary of device attributes?
if you answer "yes", please provide the following details:

         * a brief description of the vocabulary
        Is it extensible, typed, based on standard vocabularies, and so on
         * Which areas of a device's capabilities does it cover?
        These might include browser behaviour, markup compliance, physical
characteristics, messaging clients, radio behaviour etc
         * In your experience, how many device attributes do you believe
are essential to produce satisfactory content adaptation?
            - < 10
            - 10 - 20
            - 20 - 50
            - > 50


 * (x) Yes
 * ( ) No

Comments (or a URI pointing to your comments): 
The MDR vocabulary resembles much of that in UAProf, with particular
enhancements that are needed to address attributes or data types not
anticipated by UAProf. Binding to other data types are required when the
MDR is deployed, for example, as a Relational DB. Including the physical
attributes and the content/markup support capabilities, between 20 and 50
attributes are essential to enable a satisfactory content adaptation. The
additional attributes will produce superior results for specific devices.
In some cases, the MDR will record hundreds of attributes for a device,
all of which are available to the back-end service, and some of which are
an essential input to the content adaptation process.

Does the technology specify, or provide, a process or mechanism  for the
capture of attributes for a specific device?
If you answer "yes", please provide a brief description of the profiling
Is it structured or ad-hoc, empirical (using a real device) or
theoretical? Does it require a human to test the actual device? An active
network connection?

 * (x) Yes
 * ( ) No

Comments (or a URI pointing to your comments): 
The MDR is populated via a structured empirical semi-automated testing
process that augments and/or validates device information from sources
such as official manufacturer specifications. Tests are generally
conducted in real-world environments, including active mobile operator
networks. Deviations from characteristics of previous models are
specifically noted.

Does the technology specify, or provide, a technique for querying a
repository to extract device descriptions?
If you answer "yes", please provide the following details : 

         * a brief description of the query process
        e.g. DB queries, SPARQL, data is keyed or indexed
         * How can the technology export or provide device descriptions
for the purposes of content adaptation?
        e.g. standalone XML files, text configuration files
         * Do you provide APIs for applications to access the data? Which?
        e.g. Java, PHP, .NET

 * (x) Yes
 * ( ) No

Comments (or a URI pointing to your comments): 
The entire MDR can be traversed. Device- or category-specific information
can be retrieved via specific accessors appropriate to the deployment
mechanism (e.g. SQL for RDB deployments and Java APIs for clustered object
deployments). The MDR can be expressed as RDF, which makes it accessible
via other query mechanisms such as SPARQL or RQL. The MDR is delivered as
a deployable component, which can then be maintained by the customer
and/or by MobileAware. Developers can use the JSR 188 API or several
custom (optimised) interfaces to access the MDR in a deployed solution.

Do you believe that the essential device information should be publicly

 * (x) Yes
 * ( ) No
 * ( ) No Opinion

The absolutely essential device information should be available publicly
so that at a minimum every site can deliver content that is acceptable to
the requesting device. This information should include the permitted
markup, permitted media types, input and output types, dimensions of the
display. If reliable and all-encompassing, such information would
encourage the growth of mobile content. The additional knowledge captured
in technologies such as MobileAware’s MDR would then be able to further
enhance this newly-mobile content. Device manufacturers should, at least,
describe the goods they are selling. Reliable descriptions will facilitate
better adaptations, which will improve the end-user experience, which will
encourage more usage, which will benefit the manufacturers.

These answers were last modified on 12 August 2005 at 14:07:11 E.S.T.
by Rotan Hanrahan

Answers to this questionnaire can be set and changed at
http://www.w3.org/2002/09/wbs/1/ddwgld/ until 2005-09-30.


 The Automatic WBS Mailer
Received on Friday, 12 August 2005 14:10:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:00:12 UTC