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

RE: DAP rechartering

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Wed, 23 Feb 2011 08:52:50 -0800
To: "SULLIVAN, BRYAN L (ATTSI)" <BS3131@att.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D325DAF18761@orsmsx501.amr.corp.intel.com>
+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.

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.

Bryan Sullivan | AT&T
Received on Wednesday, 23 February 2011 16:53:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:25 UTC