W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2011

RE: DAP rechartering

From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Mon, 28 Feb 2011 14:45:23 +0100
To: "Tran, Dzung D" <dzung.d.tran@intel.com>, "SULLIVAN, BRYAN L (ATTSI)" <BS3131@att.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA34D4894284F@seldmbx03.corpusers.net>
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.

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.

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?

Regards
  Claes



From: 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
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] On Behalf Of SULLIVAN, BRYAN L (ATTSI)
Sent: Wednesday, February 23, 2011 8:31 AM
To: 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
Received on Monday, 28 February 2011 13:46:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:17 GMT