RE: Mobile phone capabilities list?

I believe that a repository where over time device information is marked
as 'trusted' or 'verified' in some way will be very helpful.
 
Bango looked briefly at WURFL quite some time ago and found that it
wasn't going to help us much at the time.  This is not a criticism of
WURFL, it just didn't meet our needs.
 
In particular we found that for specific devices the information would
not necessarily be complete, clearly this is likely to improve over time
as the information for a device is added to but it is far from
convenient to programmatically check that all capabilities are present
in an entry before considering using it or falling back to defaults.  
A flag or field stating whether or not the entry was complete, and/or
trusted/verified would be much simpler.
 
Another issue comes from the understanding of the semantics of the
individual devices capabilities which clearly varies from tester to
tester.  A device's screen resolution is frequently not the same as its
'usable display resolution' as the browser on the device takes up
display space with menus, header areas, margins around the page etc.
 
 
We currently use the mobile controls from the Microsoft .NET Framework,
and whilst Microsoft themselves supply device capability information,
this is updated infrequently and therefore tends to cover devices that
are considerably behind the market trends.
Bango therefore have to amend and add to the information supplied by
Microsoft, but they don't have any method for allowing us to contribute
this information to the community by including it in future updates of
their configuration files.
 
One thing they do supply is a quite nice device capability testing
suite; a set of interactive tests that the tester runs through on the
device in question with the final result being an output of the device
capability information in the correct format to add to the MS
configuration files.
 
Could something similar be employed to help automat the process of
'verifying' device information and ensuring that it is complete?
 
However even with such an approach you need to trust that the person
carrying out the testing answers the interactive tests correctly.  It
would be easy for someone for example to pay attention to the areas they
are specifically interested in and quickly skip through the rest of the
tests...
 
 
Tim Moss
CTO
Bango


________________________________

	From: public-ddwg-request@w3.org
[mailto:public-ddwg-request@w3.org] On Behalf Of Rotan Hanrahan
	Sent: 21 July 2005 09:20
	To: public-ddwg@w3.org
	Cc: www-mobile@w3.org; Steve Parker
	Subject: RE: Mobile phone capabilities list?
	
	
	Several companies create and maintain their own validated device
information repositories, which are supersets of the information
available in public. However, it takes great effort to create these
repositories and they are generally created in support of specialised
products. As a consequence, these repositories are out of reach because
they are expensive. I am pleased to report that certain key suppliers of
such repositories/products are participating in W3C MWI, with the hope
that their experience may be applied to the situation that you suggest
is the case today. An extensible, accurate, verified, trusted baseline
repository of device descriptions is one of the items on the table,
which requires the participants to examine carefully how such a
repository might operate. Much of the work will be conducted with input
from the wider community, so I welcome and encourage the feedback
expressed on the public lists.
	 
	---Rotan
	 
	-----Original Message-----
	From: Steve Parker [mailto:sparker@well.com]
	Sent: 21 July 2005 00:30
	To: Rotan Hanrahan; Holley Kevin (Centre); www-mobile@w3.org
	Cc: public-ddwg@w3.org
	Subject: RE: Mobile phone capabilities list?
	
	
	Formally, these are certainly the right standards/groups, but
the track record is disappointing in practise. In my experience, the
UAProf info actually supplied is not necessarily accurate or complete.
The URLs are not always present or correct. There is no mechanism or
procedure for correcting it - its entirely at the manufacturers' whim.
Even when the data are ok, there's a lot of useful parameters missing
from the standard. There's supposed to be a Java API, but I had to
report a bug in the JSR reference implementation months after it was
approved. It's very frustrating to anyone actually trying to cater for
all the different devices right now. Standards are one thing, but to get
something working, now, WURFL is the only show in town. I'm not an open
source zealot, but WURFL has gone further faster than the standards
bodies. It works as advertised, it's responsive, it's simple to use,
it's user extensible.
	 
	Steve

		-----Original Message-----
		From: www-mobile-request@w3.org
[mailto:www-mobile-request@w3.org]On Behalf Of Rotan Hanrahan
		Sent: Wednesday, July 20, 2005 2:07 PM
		To: Holley Kevin (Centre); www-mobile@w3.org
		Cc: public-ddwg@w3.org
		Subject: RE: Mobile phone capabilities list?
		
		
		The UAProf information, where provided and validated,
can provide some essential and objective information about mobile
devices. It has been recognised, however, that in many domains of
content authoring and adaptation that such information is insufficient.
The DDWG will be exploring the bigger picture, and looking at ways that
a general device description repository could be achieved, such that it
can encompass UAProf and other sources of information, avoiding
replication of services, and providing the necessary features of
discovery, trust, efficiency and related information management issues.
The DDWG is specifically directed to liaise with UAProf and other
related groups to this end. Planned W3C Notes will explain in further
detail, and these shall get a public airing during this year. Input from
interested parties via the public mailing list will be encouraged. The
group will also solicit specific information from key parties where
appropriate.
		 
		I hope this adds some clarity.
		 
		---Rotan.
		 
		 [ ... see mailing list archive for previous messages
.... ]