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

Re: Updated draft charter

From: <Frederick.Hirsch@nokia.com>
Date: Wed, 6 Apr 2011 13:33:17 +0000
To: <dom@w3.org>
CC: <Frederick.Hirsch@nokia.com>, <public-device-apis@w3.org>
Message-ID: <90233CD1-7669-4756-A99E-658A636225A8@nokia.com>

Thanks for the charter update. I have a few questions for clarification.

(1) Didn't we also agree to add the following to the charter?

W3C Note for  Privacy Use Cases and Requirements

Audio Volume  Reader API - API to determine current audio volume setting (but not to control it)

(2) Should we be more specific and change "An API to react to a device power status" to  "Battery Status Event Specification"  or did you have a broader scope in mind?

(3) Is "An API to discover nearby devices and services" too broad and underspecified? One of the goals of rechartering was to narrow the scope if I'm not mistaken.

(4) Is "An “intent”-based mechanism to trigger the launch of applications" the item that could include "Web Introducer" if such work were to be in the charter? I'm confused because I thought the Web Intents work was being superseded by Web Introducer. I'm not sure this can be included in the charter without appropriate WG membership, but first need to understand what this  item means, perhaps calling it an introduction mechanism would be clearer.

(5) We discussed adding "Privacy Mechanism for Device APIs" with a  note that this might move to another WG..

(6) Did we agree to  change System Information into a set of discrete identified deliverables? How does "A API to retrieve data generically from sensors"  fit with that? It seems like the original broad System Information (also change "A" to "An" here). 


regards, Frederick

Frederick Hirsch

On Apr 6, 2011, at 4:32 AM, ext Dominique Hazael-Massieux wrote:

> Hi,
> I've updated the proposed new charter for the group with the results of
> the discussions at our F2F:
> http://www.w3.org/2010/11/DeviceAPICharter.html
> In particular, I have:
> * removed the comm log api
> * split the APIs for beeps, vibrations and menu
> * added the permission API
> * added the WG note re privacy best practices
> * changed app launcher into our discussion of an intent-based mechanism
> * added device and services discovery
> * split sysinfo in network, battery, generic sensors
> * amended success criteria to mention installable Web applications
> I think the intent-based mechanism would deserve a bit more explanation;
> I'm hoping Claes could provide that.
> I haven't added the Rec-track privacy deliverable: Frederick, could you
> provide some rough description of what should be in the charter?
> I think I have integrated all the other points that were discussed, but
> please let me know if I missed something.
> Dom
Received on Wednesday, 6 April 2011 13:33:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:48 UTC