W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2009

First brick in Policy Framework: Features and Capabilites?

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 19 Nov 2009 10:34:20 +0100
To: public-device-apis <public-device-apis@w3.org>
Message-ID: <1258623260.12107.1843.camel@localhost>

Based on my understanding of the discussions at the F2F, there are two
main pieces that people would like to see coming from our work on the
policy framework for Device APIs:
• a way to identify features and capabilities of Device APIs
• a way to express restrictions of access to these in a format that
allows to interchange policies across browsers, devices and policies

I think it is still controversial or unclear whether we can usefully
work on the latter — in particular, it’s not clear to me that we have
heard many browsers say they want to integrate such a policy layer in
their implementations.

But there seems to be rough consensus on the usefulness of the former,
and there is already a fairly clear use case for it — the <feature>
element in Widgets P&C.
Moreover, I could see the definitions of these features and capabilities
being useful even in browsers, where a Web app could declare the
APIs/features it require, and the browser would use that declaration to
inform the user and restrict the available APIs to the ones in the
As we have already alluded to during the F2F, I think defining the
semantics of features and capabilities is also likely not to be a
trivial exercice.

As a result, I think a good first step for our policy work would be the
definitions of features and capabilities. 

In practice, this would mean a document that defines what features and
capabilities are with non-normative examples of how they can be used,
define the semantics of the capabilities required by the existing APIs
(e.g. Geolocation), as well as the APIs we are working on and the APIs
we are planning to work on. 
I think ideally, features would be either described in each API spec, or
automatically derivable from their WebIDLs; but before we know if that’s
indeed the best approach, it would probably be useful to describe the
features of an existing API (and I think Geolocation might be a good
target for that exercice).


Received on Thursday, 19 November 2009 09:34:30 UTC

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