RE: Publishing System Information API FPWD

Hi, 

I have the following comments on this draft (version 26 January):

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?

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?

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

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

Section 4.10 Storage:

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

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

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

Section A.2 Use Cases:

- I miss a number of use cases. Some obvious use cases are for example:

Ambient Light
   An application can adjust the screen brightness based on the ambient light level

Ambient Noise
   An application can use a warning if the ambient noise level exceeds a certain level.

Ambient Atmospheric Pressure
   A weather application can present current atmospheric pressure

   An application can present the altitude based on the atmospheric pressure 

Best regards
  Claes




> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Robin Berjon
> Sent: torsdag den 21 januari 2010 18:49
> To: public-device-apis@w3.org
> Subject: CfC: Publishing System Information API FPWD
> 
> Hi all,
> 
> this is a Call for Consensus to publish a FPWD of the System
> Information API (http://dev.w3.org/2009/dap/system-info/).
> 
> Please review the current draft which Max updated earlier today, and
> make the comments you believe you need to make before next week's call,
> at which point we'll make the decision to publish or not.
> 
> Note that there is no requirement on FPWDs to be perfect - if they were
> perfect we'd go straight to LC. They need to be good for broader review,
> and reasonably feature-complete.
> 
> Where CfCs are concerned, silence is considered to be assent, but
> positive support is preferred (even if simply with a +1).
> 
> Thanks!
> 
> --
> Robin Berjon
>  robineko - hired gun, higher standards
>  http://robineko.com/
> 
> 
> 
> 
>

Received on Wednesday, 27 January 2010 08:34:51 UTC