RE: Sensor API

Hi Tran,

See my comments inline below.

Regards
  Claes

From: Tran, Dzung D [mailto:dzung.d.tran@intel.com]
Sent: den 1 oktober 2011 18:09
To: Nilsson, Claes1; JOSE MANUEL CANTERA FONSECA; public-device-apis@w3.org WG
Subject: RE: Sensor API

Hello Claes,

Thanks for your comments.  Here are some of my thoughts (Jose might have his own opinions :)):


·         I think that a generic sensor API must support not only "in-device" sensors but remote sensors as well. At least locally connected (USB, Bluetooth, ANT+ etc) sensor should be supported. A common example is heart rate sensors but there are also other sports and health related sensors as well as other types of external sensors. The Webinos proposal supports remote sensors through the Webinos service discovery API but it would also be possible to create of version of the sensors API that supports a "stand-alone" sensor discovery feature. Which is your view on this?

>From the API  level does it matter the underneath discovery mechanism or if it is in-device verse USB connected. For instance, a USB connected heartrate monitor would be:
        var sensorConnection = new SensorConnection('sensor:HeartRateSensor');

As for networked connected services, I will comment on that in the other email thread.
[Claes:] We want to provide a generic and flexible sensor API and I think that it is necessary to provide a mechanism for sensor discovery and user selection of sensor/authorization of access. A simple example is a "weather" web application that wants to use device temperature and humidity sensors. If these sensors are provided in the user's current device as well as in an accessory some kind of sensor discovery/sensor selection mechanism is needed. However, it can be discussed whether this sensor discovery mechanism should be included in the sensor API itself or whether an overlaying service discovery API should be applicable.


·         What happens in your proposal if there is some error when listening to a sensor? In the Webinos proposal there is an "accuracy" attribute in the sensor event stating the accuracy and reliability of the sensor data.

I used to have this in my version until we merged with Jose's version. It is the accuracy attribute as:
       <dt>readonly attribute int accuracy</dt>
       <dd>
              <ul>
<li>SENSOR_STATUS_ACCURACY_HIGH - This sensor is reporting data with maximum accuracy</li>
              <li>SENSOR_STATUS_ACCURACY_MEDIUM - This sensor is reporting data with average accuracy, calibration with the environment may improve readings</li>
              <li>SENSOR_STATUS_ACCURACY_LOW - This sensor is reporting data with low level of accuracy, calibration with the environment is needed</li>
              <li>SENSOR_STATUS_ACCURACY_UNRELIABLE - This sensor is reporting data that can't be trusted, calibration is needed or the environment doesn't allow readings</li>
              </ul>
       </dd>
       <dt>readonly attribute long timestamp</dt>
       <dd>
The time in nanosecond at which the sensor data was read
       </dd>
[Claes:] Yes, we need an accuracy attribute and I also think that we need the following:

unsigned short SENSOR_STATUS_UNAVAILABLE
A constant describing that the sensor is not available and no sensor data can be provided. This accuracy attribute will for example take this value when contact is lost with a sensor using Bluetooth communication.


·         The Webinos sensor object contains metadata about the discovered sensor such as range, delay, power consumption, vendor etc. In your proposal there is no such sensor meta data. I think that there are use cases for using this meta data, for example tailoring a web application to a specific sensor from a specific vendor. Your view?



I noticed these types of metadata in the Android's Sensor API also. I didn't see any good use cases for these info, so I left it out.

[Claes:] I guess that there are reasons for having metadata in the Android sensor API. As said above this makes it possible for web applications to tailor the sensor data processing based on this metadata.



Furthermore, I am considering if we should add a sensor type "GenericSensor" or "CustomSensor". For this generic sensor type the data is just an array of float values. The metadata defines the specific sensor. I imagine that this could be used when a vendor introduces a new sensor and allows web applications tailored to this specific sensor access it without any needs for upgrading the sensor API.



Thanks
Tran,



From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Nilsson, Claes1
Sent: Thursday, September 29, 2011 8:54 AM
To: Nilsson, Claes1; JOSE MANUEL CANTERA FONSECA; public-device-apis@w3.org WG
Subject: RE: Sensor API

Hi again Jose,

I am comparing your sensor API proposal with the sensor API that I specified within the Webinos EU-project, http://dev.webinos.org/specifications/draft/sensors.html. Some quick comments below:


·         I think that a generic sensor API must support not only "in-device" sensors but remote sensors as well. At least locally connected (USB, Bluetooth, ANT+ etc) sensor should be supported. A common example is heart rate sensors but there are also other sports and health related sensors as well as other types of external sensors. The Webinos proposal supports remote sensors through the Webinos service discovery API but it would also be possible to create of version of the sensors API that supports a "stand-alone" sensor discovery feature. Which is your view on this?

·         What happens in your proposal if there is some error when listening to a sensor? In the Webinos proposal there is an "accuracy" attribute in the sensor event stating the accuracy and reliability of the sensor data.

·         The Webinos sensor object contains metadata about the discovered sensor such as range, delay, power consumption, vendor etc. In your proposal there is no such sensor meta data. I think that there are use cases for using this meta data, for example tailoring a web application to a specific sensor from a specific vendor. Your view?

Best regards
  Claes

From: Nilsson, Claes1
Sent: den 29 september 2011 10:35
To: 'JOSE MANUEL CANTERA FONSECA'; public-device-apis@w3.org WG
Subject: RE: Sensor API

Thanks for this proposal Jose. Nice that sensor APIs is getting more attention in DAP.

I'll review your proposal and will provide comments.

Regards
  Claes

From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of JOSE MANUEL CANTERA FONSECA
Sent: den 28 september 2011 19:50
To: public-device-apis@w3.org WG
Subject: Sensor API
Importance: High

Hi there,

At [1] you can find a first editor draft of a proposed Sensor API. It is a contribution coming from a joint effort between interested members in W3C DAP (particularly Dzung)  and the Wholesale Applications Community (WAC). This e-mail is intended to introduce such an API to the whole W3C DAP Community in order to start discussions around it. We think this is interesting work to be picked up by the W3C DAP Group. In fact we are already working on prototyping it. I have asked Robin to add an slot in the TPAC F2F meeting agenda.

It is our intention that this particular API could be a first example of alignment between the WAC and W3C Communities in order to create joint Device APIs specifications, that can reach the Rec status in a reasonable timeframe.

Your comments, feedback and contributions are really welcome and needed to progress this work.

Many thanks

All the best

[1] http://dev.w3.org/2009/dap/system-info/Sensors.html

________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx