[wbs] Johan Hjelm response to 'Device Description Technologies Survey'

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



---------------------------------
Name of device description technology or device description product
----


Answer: 
OMA Device Management (OMA DM)firmware update mechanism (FUMO)




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

Answer: 
Open standard




---------------------------------
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?

Answer: 
The OMA DM FUMO is used for updating software in a terminal, such as a
mobile phone. In this regard, it changes the characteristics of the
terminal. 




---------------------------------
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
 * [x] 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)

 





---------------------------------
What are input and output features supported by your product ?
----
Input



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

 
There are no constraints as such.




Output



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

 
There are no constraints as such.




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

Answer: 
The update (which can be initiated from the user or other authorized
party, e.g. an operator) transmits a management tree (standardized in OMA
DM) and the relevant uploads. When executed, the management tree is
updated and returned. 

See 

http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/OMA-AD-FUMO-V1_0-20050926-D.zip

and

http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/OMA-AD-DM-V1_0-20050530-D.zip





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

Answer: 
OMA DM is based on XML. The transfer protocol is based on SyncML and other
standard protocols. 




---------------------------------
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
data?
        e.g. per model, per operator, per browser etc
         * How does the technology manage multiple revisions of the same
device?
        (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): 
Each OMA DM server serves as a repository for the management trees in its
domain. See further the OMA DM AD.




---------------------------------
Vocabulary
----
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 OMA DM vocabulary is limited to those aspects of the terminal which
can be influenced remotely, e.g. software and configurations. 

The architecture is intended to allow for extensibility. Since device
manufacturers will always develop new functions in their devices and since
these functions often are proprietary, no standardized management objects
exist for them.  To make these functions manageable in the devices that
have them, a device description framework is needed that can provide
servers with the necessary information they must have in order to manage
the new functions. The intention with this framework is that device
manufacturers will publish descriptions of their devices as they enter the
market. Organizations operating device management servers should then only
have to feed the new description to their servers for them to
automatically recognize and manage the new functions in the devices.

For a detailed description, see
http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/OMA-DM-StdObj-V1_2_0-20050131-D.zip






---------------------------------
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
process. 
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 OMA DM client builds a management tree, and synchronizes it with the
DM server. This process is real, works, and has been demonstrated. It uses
a network connection to transfer data, but not to build the management
tree. 




---------------------------------
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): 
See the OMA DM AD.




---------------------------------
Do you believe that the essential device information should be publicly
available?
----




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

 
This is the opinion of Ericsson. It does not necessarily reflect the
opinion of other users of the standard, nor that of Ericsson in particular
deployments of systems based on OMA DM. 


These answers were last modified on 30 September 2005 at 07:37:16 E.S.T.
by Johan Hjelm

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

 Regards,

 The Automatic WBS Mailer

Received on Friday, 30 September 2005 07:40:10 UTC