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


From: Marcin Hanclik <Marcin.Hanclik@access-company.com>
Date: Wed, 7 Oct 2009 11:05:32 +0200
To: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <FAA1D89C5BAF1142A74AF116630A9F2C2890D48729@OBEEX01.obe.access-company.com>
Hi All,

This are my comments to the actions 15 and 25 [A15], [A25], i.e. about features and capabilities.
Yesterday I provided the info about features [1], those consideration reflect the topics we discussed in BONDI.

Here are some thoughts on features and capabilities and how they (could) play together.
The initial note is that BONDI defines APIs (methods, attributes) based on WebIDL and those APIs are grouped as WebIDL modules.
Modules are to be kept independent (i.e. you can use API from one module without requiring other modules) for simplicity (this is a short-term goal, probably not realistic in the long run).

BONDI defines the device capability and feature as follows [2] (section 7):

A Device Capability is a specific capability of a device that may be exposed via a JavaScript API. From the point of view of a Web Runtime, a Device Capability would typically be exposed via an API of the underlying platform. However, Device Capabilities are defined and identified in a portable way, without a dependency on any specific software platform or platform-specific API.
A Feature is a specific set of functionality provided by a Web Runtime, as made available by a defined set of JavaScript interfaces and behaviours. Features are hierarchical, in that one feature may itself be made up of a number of sub-features. A Feature is identified uniquely by IRI, and is the unit of expression of dependencies by BONDI Web Applications.

P&C defines the feature as follows [3]:
" A feature is a runtime component (e.g. an Application Programming Interface or video decoder)..."

The definition of a feature in BONDI matches the corresponding definition in P&C, it restricts it to formally JavaScript interfaces, but we also have other features (e.g. "http://bondi.omtp.org/meta/ui?background=true&hidden=false" in [4], section A.2.1).
Therefore we realize that features are not only APIs.

Device Capabilities are exposed via APIs and Features are made available by JavaScript interfaces.
So, as for me, they are very similar.
The basic difference is that Device Capabilities are to be defined in a portable way.
Therefore BONDI assumes that APIs may change (across devices, platforms etc), but Device Capabilities will not.
Device Capabilities have abstract definitions [4], not tightly related to APIs.

Section B.5 of [5] - about resource attributes - requires that a feature is always specified in a corresponding query, whereas a device capability is optional.
This means that each device capability is related to some feature, but not each feature must be related to a device capability.
It allows e.g. only "authenticated" APIs to access some resources (depending on the security policy).

On the BONDI API level, we may build another picture based on [6].
The APIs (methods, attributes) are covered by features.
The scope of a feature (i.e. the methods and attributes it covers) is limited to the module (in WebIDL sense), so are the use cases I mentioned in [1].
We could perceive the feature as a selector (pointer etc) to some set of APIs.

On the other hand, one device capability is mapped to (or by, depending on the mapping direction) multiple features and those features are not limited to stem from one module (in WebIDL sense).
Therefore we could perceive the device capability as a selector (pointer etc as above) to some cross-module set of API.

To sum up:
a) we need device capabilities to make a distinction between architecture and APIs. I.e. if we want the DAP architectural part to be extensible and e.g. to be used without the DAP APIs.
b) device capability is about portability, i.e. the security policy based on device capabilities shall be portable. The IMPORTANT requirement is, however, that the mapping between APIs, features and device capabilities is of crucial importance to the actual security. I.e. the UA must know which API is mapped to which feature and to which device capability. This in turn means that only part of the security policy is actually portable.

I hope this helps.


[A15] http://www.w3.org/2009/dap/track/actions/15
[A25] http://www.w3.org/2009/dap/track/actions/25
[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0068.html
[2] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_v1_01.pdf
[3] http://www.w3.org/TR/widgets/#feature0
[4] http://bondi.omtp.org/1.01/apis/devcaps.html
[5] http://bondi.omtp.org/1.01/security/BONDI_Architecture_and_Security_Appendices_v1_01.pdf
[6] http://bondi.omtp.org/1.01/apis/apifeatures.html

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com


Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda


This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Received on Wednesday, 7 October 2009 09:06:12 UTC

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