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>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<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
>
>
>
>