RE: DAP rechartering

Hello,

Maybe model the Sensor APIs after  the Android Java Sensor API or Windows Mobile Sensor API?

Thanks
Dzung Tran

From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Tran, Dzung D
Sent: Tuesday, March 01, 2011 3:18 PM
To: Rich Tibbett; Nilsson, Claes1
Cc: SULLIVAN, BRYAN L (ATTSI); public-device-apis@w3.org
Subject: RE: DAP rechartering

Hello,

There is a section in the System Info about Sensors. I would suggest breaking this out of System Info and create a Sensors specification.

Agreed, that extensibility/discoverability for sensors is a nice to have and difficult to achieve since there are so many different values that can return from different types of sensor.

Most of my experience around working on Geolocation and Android’s browser and how it can be done via a bridge between native and Java. I would think that similar thing can be done for other sensors.

Thanks
Dzung Tran

From: Rich Tibbett [mailto:rich.tibbett@gmail.com]
Sent: Monday, February 28, 2011 7:55 AM
To: Nilsson, Claes1
Cc: Tran, Dzung D; SULLIVAN, BRYAN L (ATTSI); public-device-apis@w3.org
Subject: Re: DAP rechartering

Hi Claes, Dzung,

On Mon, Feb 28, 2011 at 2:45 PM, Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com<mailto:Claes1.Nilsson@sonyericsson.com>> wrote:
Hi Dzung,

I am also interested in addressing sensors. We have had discussions at the DAP list on this matter and there are worries about scope creep. Richard wants us to take small steps and has proposed an events model (similar to DeviceOrientation event draft http://dev.w3.org/geo/api/spec-source-orientation.html ) for well-known sensors (http://lists.w3.org/Archives/Public/public-device-apis/2011Feb/0050.html).  I agree that this is a good approach for common use cases where access to sensors that are well-known today is required.

Yes. There would be a lot of value to exposing well-known sensors without trying to pack in extensibility and discovery in the first instance.


However, this does not solve access to general sensors, actuators, accessories etc and the web is behind native application environments that provide Bluetooth, USB and RFID/NFC APIs.

These things wouldn't have to be excluded from the charter - just that extensibility and discovery are nice-but-complex features when we could more easily target the low-hanging fruit of exposing discrete, simple-but-high-value sensors in the first instance (as noted above, in a similar way to the Device Orientation Events API and reusing a lot of the work from the System Info API initiative).

We should separate these things in the charter.

There'd be no reason why we couldn't consider producing things like (for example) a Bluetooth/USB/RFID Device Connection API and an OBEX-JavaScript-Interchange API under the new charter. Such things could be filed under 'Other deliverables' or in plain English: 'a few deliverables we would explore and *might* produce, pending workable input proposals'. That would remain separate to the discrete sensors stuff that would be filed under 'Deliverables' in the charter or: 'things we *will* produce since we have a good idea of how to do them today'. Whether we need to settle on the discrete sensors to expose in the charter is an open question from me. I'd like to pin-point the exact sensors we would plan to expose very early on.

Proposals would be interesting in that area of discoverability and extensibility. It's just really really hard compared with exposing some simple, discrete sensors to the web that would already provide a lot of value-add.


Dzung, I am curious on your view. What do you propose? Could we provide something flexible but still reasonable simple for developers? Furthermore, Bryan, Paddy, you have mentioned that Bondi sensor/Bluetooth API. Any experiences on these APIs you can share?

For the charter Richards proposes that we just state that we are providing an events model for well-known sensors. Any additional extensibility/discoverability/low-level API proposals could be considered for publication under the charter term. Such an approach would sounds nice and flexible but would this approach work from the W3C Patent policy point of view?

As far as I know, royalty-free on W3C specs is only established once it completes all the patent exclusion periods. That's not really something that can be known before the group starts to produce something. Anyone care to elaborate on that?


Regards
  Claes

Cheers,

Rich




From: public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org> [mailto:public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org>] On Behalf Of Tran, Dzung D
Sent: den 23 februari 2011 17:53
To: SULLIVAN, BRYAN L (ATTSI); public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: RE: DAP rechartering

+1 agreed.

I was planning to send out a message about rework of System Info, but I think this is well said below. Also when DAP started, we wanted to work on a sensor APIs, which were put on hold till v2 with agreement from the group. We should revisit these sensor API.

Thanks
Dzung Tran, Intel

From: public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org> [mailto:public-device-apis-request@w3.org<mailto:public-device-apis-request@w3.org>] On Behalf Of SULLIVAN, BRYAN L (ATTSI)
Sent: Wednesday, February 23, 2011 8:31 AM
To: public-device-apis@w3.org<mailto:public-device-apis@w3.org>
Subject: DAP rechartering

I commented on the call that if the group decides to change the approach to discrete system information property access and sensors, away from the current approach of the Sysinfo spec (an common interface through which various properties can be accessed), I suggest rather than try to evolve the current spec in that direction, DAP start new with new spec(s) for the discrete purposes. This would allow as Richard proposed, that the implementers be able to focus on discrete properties/sensors as they become needed and implementable. It will also help avoid the potential fragmentation with other API designs that do exist in the market, which are more aligned with the intent of the Sysinfo design as it stands today, and are supported by a number of implementations already.

This is in general an approach I think DAP should take with the APIs in its charter. Where it has not completed work on APIs that were in fairly complete form when originally submitted as input to DAP two years ago, that indicates to me a difference in vision and API design approach which may not easily be resolved at this point. DAP should not continue to struggle with what may be a working approach with limited success potential, i.e. trying to merge to significantly different visions for APIs into a single set of specs. If W3C was able to complete these specs, in the end they probably would just confuse the market and cause fragmentation impacting vendors which have to implement two APIs for the same purpose (with different widely models for API design, user interaction necessity, and security/privacy).

Thus I think DAP should drop those APIs it has not finished and focus on new work that does not conflict with the other work in these areas which has continued in the market in the last two years, and which is now widely supported, and likely to be brought to W3C for standardization in the near future. This sequence should be familiar to W3C members: market initiative and W3C response (group/work initiation), with implementations continuing to be developed, and eventually driving W3C to refocus on supporting the actual implementations in the market. DAP has the opportunity in this rechartering phase to recognize and respond to that need for realignment in the work that W3C is doing in this area.

We still firmly support the API scope in the original DAP charter, but I question if it’s effective to keep struggling to address them under DAP’s new charter. Thus I would rather see DAP focus on a unique API scope, to avoid market fragmentation.

Thanks,
Bryan Sullivan | AT&T


Error! Filename not specified.