RE: Rechartering Device APIs & Policy Working Group

Regarding A1 I agree that an event model according to the DeviceOrientation Event () is elegant. For certain types of sensors delivering simple values this will probably work well. However, according to my earlier mail we still have a problem with addressing sensors/actuators/accessories that are not exactly defined today. An example is “mobile healthcare”, which is an area that is rapidly increasing. Do you mean that it is too early to address this sector?

I know that this is tricky and I don’t know how far we can go and still have APIs that are reasonable easy to use by developers. More investigation is needed. So, how “exact” does a charter have to be? I understand that a good level of clarity is needed, e.g. due to IPR reasons, but do we already, in the charter, have to state that we limit ourselves to an event based model for sensors. Couldn’t we just say that we with continue with the work on sensor API. If we then came to the conclusion that the solution is to create a set of “hard” event based APIs as well as a low level API that is easily mapped on Bluetooth, Bluetooth Low Energy and ANT+, would that be ok?

Regards
  Claes

From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Rich Tibbett
Sent: den 8 februari 2011 13:42
To: Dominique Hazael-Massieux
Cc: public-device-apis
Subject: Re: Rechartering Device APIs & Policy Working Group

This initial proposal looks good. Here are some thoughts on the proposed charter:

- We still need to define the scope of the deliverables (Section 3) a bit better. We have quite a number of deliverables on the list. We want to get these things implemented and having a laser focus on things that are implementable might be a really good start. Also, we have to keep things as simple as possible. For example, instead of jumping straight to generic events there's a lot of value in specifying well-defined sensor events initially). Below are some thoughts per item on the charter.

Section 3:

Work items that I would really like to see included in the charter:

A1. Sensor Events: reworking the System Info API to a set of well-defined sensors based on reusing the events model of the Orientation API (). Initially focused on a well-defined list of sensors (such as termperature, light, proximity, noise, pressure, etc) and then potentially exploring extensibility and sensor discoverability as a future work item.

A2. Media Streaming: the DAP activity should pick up some of the slack from this RTC-Web initiative and/or coordinate with the RTC-Web initiative on additional specifications required. Actually, it's going to be important to clearly delineate the RTC-Web and DAP deliverables but DAP has a significant part to play in this work.

A3. HTML Media Capture: let's continue to move the HTML Media Capture spec through the W3C process: http://www.w3.org/TR/capture-api/


A4. PIM APIs (minus tasks). These are intended for more longer term consideration and implementation. I don't expect full browser support while browser vendors are still focused on implementing more prioritized HTML5 features. We can also do a number of things without implementing the full API in lack of widespread support. However, it may be possible to move these through the W3C process based on implementations that we already have and other implementations that will come online during the chartered term. 'Tasks' seems to be a very low priority compared to Contacts, and to a lesser extent, Calendar.

A5. Context Menus API: The ability to create menus that apply to defined user agent contexts (e.g. address bar menus, right-click menus for images/video/text, speed dial menus, etc). An example of the type of API in mind is available here: http://www.opera.com/docs/apis/extensions/backgroundprocessguide/#bp23. Opera also have a full W3C-style specification ready to go for kicking off this work (if it gets adopted in to the charter).

Work items that I don't think we should put in to our charter initially due to implementation concerns (interface, technical, political):

B1. Messaging API: we have sms, mmsto and mailto URIs that are sufficient for adding messaging in to our products without the need of an additional API. In the future we could look at developing extensions to e.g. XHR for advanced messaging features (success/error callbacks, attachments) but this is not the initial priority. The first step is to integrate communication services in to browsers and we don't need a new API for this purpose.

B2. Capture API: The jury is still out on whether its necessary for a web app to be able to programmatically capture audio, video and images from a user's device. The UI for these interactions is a little painful and we have other methods (e.g. the HTML Media Capture spec for this purpose).

B3. Application Launcher API: Custom URL schemes and URL resource mime types launch native apps, not APIs.

B4. Communication Log API: I can't find any significant use cases for providing the communication log to web apps. If necessary, a communication log can be uploaded by the user as a file or mounted via the File System API for the web app to access.

B5. Gallery API: Both the File API and File System API promise to deliver functionality similar to this proposal. It's not core enough to get wide implementation IMO.

Work items that might be potential work items to live under the new charter:

C1. File System API: While file system fits well in the WebApps group, the File System API is really suited to fall under our charter.

C2. HTML <device>: Initially incubated on the DAP mailing lists (with Hixie), it might be nice to push forward development of this stuff in W3C via DAP (though see my discussion on the relationship of the new DAP group with the RTC-Web initiative above). FWIW, this is not specified in the W3C's HTML5 snapshot since it is a current work item in WHATWG. It might be nice to give <device> a home in W3C DAP (or coordinate how that will work with the RTC group if/when it gets chartered).

Other comments on the charter proposal:

- Remove the requirements for the delete paradigm from our APIs. Simply, we have yet to work out a way to represent delete in the UA while additional non-web interfaces, such as management consoles and configuration windows, are a much better way to provide delete functionality that the user controls.

- We don't need to publish a Working Group Note on the Design Patterns that we choose (included in Section 3.2: Other deliverables). Design Patterns vary depending on the problem put in front of us. There is likely not a single design pattern for all of our deliverables.

That's it for now. Any feedback is appreciated.

- Rich


On Wed, Feb 2, 2011 at 3:09 PM, Dominique Hazael-Massieux <dom@w3.org<mailto:dom@w3.org>> wrote:
Hi,

The current charter [1] of our Working Group will expire at the end of
June this year; it is pretty clear that our work will not be done by
then and thus will need to extend or renew our charter.

Given that our understanding of the work that needs to be done has
evolved quite a bit, and also due to the lack of involvement of
potential implementors of our work in the group, the Chairs and Staff
Contacts are suggesting that we should try to refine our charter and
have it reviewed by W3C Advisory Committee.

To that end, I've been working on a proposed new charter for the group:
http://www.w3.org/2010/11/DeviceAPICharter.html


This charter introduces several important changes — which are all up for
discussion.

The most important change is the removal of the Policy Framework as a
deliverable of the group. That proposed change is motivated by the
following reasons:
* the work has only had limited traction in the group so far,
* the policy framework is architecturally independent of the APIs, while
its bundling with our work on APIs has been the source of
misunderstandings from potential implementors.

To reflect the removal of the said framework, we're proposing to rename
the group to "Device APIs Working Group" — although the group would
still be referred as DAP since that's now a well-known moniker.

The removal of the Policy Framework doesn't mean that the group would
stop working on security. On the contrary, the new charter puts a strong
emphasis on the needs surrounding security and privacy (privacy which
was actually missing from the previous charter.) We've already received
feedback that the current wording around security isn't satisfying and
welcome proposed changes to the text.

Finally, the new charter tightens the scope of our APIs to reflect the
ones we've actually been working on — the very broad scope of our
current charter has been an explicit showstopper for some W3C Members to
join the group.

You can see a diff between the two versions of the charter at:
http://www.w3.org/2007/10/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2009%

2F05%2FDeviceAPICharter&doc2=http%3A%2F%2Fwww.w3.org%2F2010%2F11%
2FDeviceAPICharter.html

We very much welcome feedback and suggestions on this new charter, which
will also be discussed during our F2F in Seoul.

Dom

1. http://www.w3.org/2009/05/DeviceAPICharter