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

Re: [SysInfo] Wiki Page and a proposal for the API structure

From: Max Froumentin <maxfro@opera.com>
Date: Mon, 30 Nov 2009 14:19:39 +0100
Message-ID: <4B13C66B.9030407@opera.com>
To: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
On 27/11/2009 10:07, JOSE MANUEL CANTERA FONSECA wrote:

> 1) Regarding you separation between devices and properties I would be careful as sometimes I can need information about an specific input device, for example the active camera or the primary camera. The same can apply to other hardware elements. I think in this case the API has to be more sophisticated. For example in Bondi we defined well-known identifiers for components (aspect instances) in order to differentiate between them

Indeed, it is to account for all similar devices that are available. And 
mapping the information from each device to its hardware characteristics 
is desirable, and could perhaps be achieved through a simple identifier. 
I need to think about that.

> 2) I'm not sure that the sysinfo API is only concerned with hardware components but also with any other kind of component installed or related to the device which can be in an specific state. For example, is a network a hardware element? I don't think so.

No, of course. I used hardware for lack of a better term, but I'm well 
aware that some properties have nothing to do with hardware. I'll try to 
get the terminology right, at least in the draft.

> 3) The properties you enumerate are useful but arbitrary in the sense that I can consider other properties as useful as the ones you are considering. My proposal is to define by consensus the DAP Core Vocabulary in the same way we in the DDWG we defined the DDR Core Vocabulary. This DAP Core Vocabulary would constitute the minimal agreement between the DAP members about what information should be exposed by the API at a minimum. However the API should be prepared for exposing properties coming from vocabularies provided by vendors or industry initiatives such as Bondi, Jil or others.

As I mention in the wiki, the list is indeed completely arbitrary at 
this point, and only serves to illustrate the point of API separation.
Coming up with a final list is a lot of work, and to be honest I hope 
you, of all participants, will be able to help.

> In any case such DAP Core Vocabulary should have well-defined mappings with the DCO.

Indeed, and ideally with Bondi's too.

Max.
Received on Monday, 30 November 2009 13:20:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT