SingleSensorSpecification

Initial Approach was a Generic API

Originally DAP had a System Information API specification that included Device Characteristics, Sensors and Network Information all in one specification. The material included a wide range of information, much of it unrelated with an API that allowed retrieval or monitoring by property. The following image from that draft highlights this:

Rationale and reasons for changing approach

The Working Group (WG) saw a number of concerns with this approach in terms of some considerations:

1. Testability

The specification covered a wide range of material, many of which we did not expect implementations or the ability to test. Thus we would need to remove material from the specification to enable testing and completion.

2. Matching meaning and API requirements to specific sensor or device characteristics

There was no unifying theme other than a generic interface based on properties and property monitoring. We anticipated requirements would depend on the meaning and use cases for the specific sensors or information and thus require some unique API considerations and definitions.

For example, the Battery API defines what it means to have a virtual battery composed of individual batteries, events related to Battery charging and discharging, unique to this specification.

3.Complexity can be hidden in a generic interface

Making a generic interface would require leaving some details the application using it or creating some ambiguity around some details.

For example, a simple interface based on retrieving properties would not speak to how multiple sensor instances are to be treated in terms of aggregation, independent retrieval and monitoring or discovery ( ISSUE-121 ).

4 Decoupled time tables for implementation, W3C Process, and testing.

We saw value in decoupling the various sensors to enable independent specification development, testing and progression. If we had a generic specification we would still need a means to demonstrate testing for the various types of sensors to have a meaningful result.

Subsequently we have seen some sensors have more interest than others, for example we have two Battery and Vibration implementations in progress, but only one for Ambient Light.

5 Value of simplicity

We recognized that simple and short specifications are easier to understand and test and limit the scope of discussion and other concerns.

At this time we understand that with sufficiently detailed implementation experience some material can be abstracted into a coherent interface, offering consistency to developers. It is also a fact that there is much work that has either been completed or is well on its way to completion

Next Steps

An appropriate way forward seems to be the following:

1. Complete the few current short and simple API specifications under development, for which implementations already exist.

2. consider a v.next effort to create a new unified generic API if it offers enough value.