Re: Rechartering Device APIs & Policy Working Group

Hi Claes,

Thanks for the feedback.

On Tue, Feb 8, 2011 at 2:11 PM, Nilsson, Claes1 <
Claes1.Nilsson@sonyericsson.com> wrote:

> 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?
>
>
>
It's good to discuss this now as I'm particularly worried about scope creep
hence the request for more discussion and focus on the intended
deliverables. In this instance I think it helps to say that we'll deliver an
events model for well-known sensors. If someone were to then propose
extensibility and discoverability proposals during the charter term, or a
low-level API as you suggest, then we could take a look and we could
consider it for adoption and publication under the charter.

It is generally a good idea to take smaller steps in producing web
standards. I doubt we'd get any complaints if we under-promised and
over-delivered with the group deciding to publish APIs similar to those that
you're suggesting on top of a really useful and solid base specification. On
the other hand, we *can* promise upfront the smaller steps which will add
real value to web developers and that may help to inform and create more
advanced discussions that might end up as recommendations in their own
right.



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