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

RE: ISSUE-14: Gathering requirements [System Info & Events]

From: Tran, Dzung D <dzung.d.tran@intel.com>
Date: Wed, 7 Oct 2009 07:35:55 -0700
To: "Jere.Kapyaho@nokia.com" <Jere.Kapyaho@nokia.com>, "david.rogers@omtp.org" <david.rogers@omtp.org>, "Claes1.Nilsson@sonyericsson.com" <Claes1.Nilsson@sonyericsson.com>, "robin@robineko.com" <robin@robineko.com>, "jmcf@tid.es" <jmcf@tid.es>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <753F67ADE6F5094C9F1DBA00D1BAA8D312C3BDD246@orsmsx501.amr.corp.intel.com>
If we don't cover sensors in this WG, which WG would cover this? As the name of the WG as "Device APIs", it makes sense that we should cover this important feature of the device.

Dzung Tran

-----Original Message-----
From: Jere.Kapyaho@nokia.com [mailto:Jere.Kapyaho@nokia.com] 
Sent: Wednesday, October 07, 2009 02:37 AM
To: david.rogers@omtp.org; Claes1.Nilsson@sonyericsson.com; Tran, Dzung D; robin@robineko.com; jmcf@tid.es
Cc: public-device-apis@w3.org
Subject: Re: ISSUE-14: Gathering requirements [System Info & Events]

On 6.10.2009 18.36, "ext David Rogers" <david.rogers@omtp.org> wrote:
> The question remains as to whether we should consider the subject of a sensors
> API as in-charter. Having re-read the charter, at the moment, I would say no.
> With the existing API proposals we have on the table I think we have a large
> amount of work and scope creep could be dangerous, taking apart any other
> potential IPR concerns.

The charter says the WG will deliver at least those API specifications that
are explicitly listed. That does not rule out sensors as such, or indeed any
other APIs that are not listed. It's a different matter whether the sheer
number of deliverables would already prohibit that.

Important use cases for accelerometers should at least be considered, but it
wouldn't make sense to define just a dedicated accelerometer API, since we
already know that there are other such sensors too, probably enough to
warrant a "universal" or extensible framework for sensor data access.

> Perhaps there is scope to start a separate discussion about the whole subject
> of transducers, not just sensors, With a view to re-chartering once there is
> something on the table (perhaps within the next year)? I wonder if the SCADA /
> PLC community would be interested in that part too?

Can you elaborate on the concept of transducers in this context? That might
help us determine the need for such a framework as hinted above. Somehow I
wouldn't think rechartering is necessary with sensors as we know them on
phones, but based on the little I know about SCADA it suddenly makes me
think "version 2, if ever". :-)

Received on Wednesday, 7 October 2009 14:36:30 UTC

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