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

[Policy] identifying APIs

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Tue, 6 Oct 2009 13:42:02 -0400
Message-Id: <6E455E30-3740-4D3D-AB1F-7EFD0AE0F256@nokia.com>
To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>
Earlier I listed some of the higher level requirements and goals to  
consider for DAP API Policy [1]. One of these was:
"10. Able to identify an API by URI"
I should note that URI need not be the only approach, though my  
inclination was to start with URI.

An example of the first approach, using a URI, is BONDI 1.01 which  
defines IRIs for the various APIs (section 4.2 BONDI architecture and  
security [2]).

A second approach is to use class names, as Marcin noted in the Access  
workshop position paper [3]  - APIs could be identified by Javascript  
class name and optional property attribute (see the table in 3.3).

A third approach is to not name APIs at all, but pass material in the  
API invocation to enable use, passing a capability. But for an  
enforcement engine to evaluate declarative policy it  would still need  
to be able to name APIs, I would think.

This raises a couple of questions: is the DAP API work restricted  
solely to Javascript or should the model support other languages  
(degree of language independence needed), and does declarative policy  
require the ability to name an API (regardless of whether feature  
access control is included).

It seems to me we need naming and that URIs offer more flexibility. Is  
this a decision easily made, or is discussion required?

regards, Frederick

Frederick Hirsch
Nokia


[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Sep/0126.html

[2] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf

[3] http://www.w3.org/2008/security-ws/papers/ACCESSPositionPaper_W3CSecurityWorkshop.pdf
Received on Tuesday, 6 October 2009 17:42:53 UTC

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