W3C home > Mailing lists > Public > public-device-apis@w3.org > January 2010

Re: Publishing System Information API FPWD

From: Max Froumentin <maxfro@opera.com>
Date: Wed, 27 Jan 2010 11:43:06 +0100
Message-ID: <4B6018BA.1060206@opera.com>
To: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>
CC: "'Robin Berjon'" <robin@robineko.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Claes, thanks for the feedback. See below for responses.

On 27/01/2010 09:34, Nilsson, Claes1 wrote:

> Section 4.7 Network:
> The value range for currentSignalStrength attribute is undefined.
> Should it be a number between 0 and 1 representing a "minimum" and
> "maximum" signal strength level?

True. Fixed.

> Section 4.8 Sensors:
> - AmbientLight: The value range for the "intensity" attribute is
> undefined. Should it be a number between 0 and 1 representing a
> "minimum" and "maximum" intensity level?

I sort-of agree. But then shouldn't we make all the sensors return a 
normalised value, for the sake of uniformity? That wouldn't work so well 
for the atmospheric pressure, or ambient temperature, I think.

> - Proximity: How does a "proximity"-sensor work? If you hold the
> device in your hand the object nearest to the device is your hand. If
> you put the device on a table the nearest object is the table. If you
> have the device in your pocket the nearest object is the pocket.
> Which are the use cases? How to separate any other object from the
> object that "holds" the device?

I don't really know, and I haven't done much research on proximity 
sensors. Experts answers welcome!

> - Robin states below that W3C specification for FCWD should be
> "reasonably feature-complete". I am considering this.
> For sensors we have as I understand a resolution that "sensor that
> are often used by web applications should be easy to access by web
> developers" and be covered by the System Information API
> specification. Sensors that are more seldom accessed should be
> covered by a "full generic sensor API" that is subject to future
> work. OK. Looking at section 4.8 it covers "values of external
> sensors, reflecting the device's environment". The selection of
> sensors is consistent considering that they should represent the
> "device's environment". However, looking at this list with the view
> "sensors that are often used by web applications" then the priority
> might be different. I would say that common training use cases would
> motivate "Heart rate sensor" and "Step counter sensor" and maybe a
> "Blood pressure sensor". So, is the door open for any additional
> sensors, e.g. a set of "values of external sensors, reflecting the
> user's condition" due to the view "often used by web applications" or
> is the door closed?

I for one consider that the door is open and I'm hoping for more input 
on what sensors we should support. I don't think we would break the 
"feature-completeness" of the specification if we had that discussion 
after the FPWD is published and came to the conclusion that more sensors 
were needed.

> Section 4.10 Storage:
> - The constants for type to be considered. Wouldn't it be interesting
> to separate built in RAM and memory card?

Isn't that distinction properly captured throught the isRemovable attribute?

> - Why different data types for "capacity" (unsigned long) and
> "availableCapacity" (int)?

Fixed, thanks. (aside: I'm not really sure why WebIDL defines more than 
one integer type -except for unsigned- and, as a consequence, which to use)

> Section 4.12 Input Devices
> - Editorial error for attribute "microphones []" as it says "The list
> of cameras attached".


> - Editorial error for Camera property, attribute "maxZoomFactor" as
> it says " ...must be null is hasPhysicalZoom is false".

Changed with "<dd>The maximum zoom factor of this camera. This value 
MUST be <code>null</code> if the camera doesn not have a zoom (whether 
physical or digital)</dd>"

> Section A.2 Use Cases:
> - I miss a number of use cases. Some obvious use cases are for
> example:

I've not touched that section recently, as I'm not sure it should be in 
the document. Use-cases (and requirements) are helps, meant for writing 
the specification itself, but not part of the specification. Examples 
are ok, as they help the implementer get a quick overview of a specific 
API. That's why I have one at the beginning of each section. But 
use-cases are just as well replaced by more generic wording saying "this 
specification enables webapps to do XXX, YYY and ZZZ". I'd welcome a WG 
decision on this, so I've opened ISSUE-70


Received on Wednesday, 27 January 2010 10:43:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC