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

Hi all,

I'm not saying I disagree, but from a coordination viewpoint, is this not a scatter-gun approach? Did we not agree on a prioritisation for which APIs we were going to deal with first? What happens if someone starts on another API for something else?  

Chairs, please could you give some direction on the next steps? I'm concerned that a lot of parallel activities are going to start, then stall.

Thanks,


David.
David Rogers
Director of External Relations, OMTP

-----Original Message-----
From: 이원석 [mailto:wslee@etri.re.kr] 
Sent: 09 October 2009 03:21
To: Tran, Dzung D; 전종홍; David Rogers; Nilsson, Claes1; Jere.Kapyaho@nokia.com; robin@robineko.com; jmcf@tid.es
Cc: public-device-apis@w3.org
Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]

Dear Tran, Jonathan and all.

I basically agree with Tran's opinion.
Concerning API for contactless communication devices (NFC, RFID), I believe this API should be supported for web application.
Because RFID is quickly deployed in the industry and currently this is used as an identifier for connecting things in physical world(e.g. poster, product) to information/services of internet. In this context, various kind of valuable application could be implemented based on this API for mobile devices.

Best regards,
Wonsuk
.

> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Tran, Dzung D
> Sent: Friday, October 09, 2009 5:40 AM
> To: 전종홍; David Rogers; Nilsson, Claes1; Jere.Kapyaho@nokia.com;
> robin@robineko.com; jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]
> 
> Hello,
> 
> Look like there is consensus that sensors need to be covered in the Device
> APIs. I will take the action to take a first stab at the requirements for
> sensors. We can decide later if it should be part of System Info & Events
> or a separate API section.
> 
> Thanks
> Dzung Tran
> 
> -----Original Message-----
> From: 전종홍 [mailto:hollobit@etri.re.kr]
> Sent: Wednesday, October 07, 2009 08:51 AM
> To: David Rogers; Nilsson, Claes1; Tran, Dzung D; Jere.Kapyaho@nokia.com;
> robin@robineko.com; jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]
> 
> Hi,
> 
> I think we need to consider also the contactless communication devices
> and their properties and APIs(NFC reader/tag, RFID reader/tag, etc).
> 
> http://dev.w3.org/2009/dap/api-reqs/

> 
> •MUST enable listing contactless communication devices (NFC, RFID) and
> their properties; 
> 
> Best Regards,
> 
> --- Jonathan Jeon
> 
> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of David Rogers
> Sent: Wednesday, October 07, 2009 12:36 AM
> To: Nilsson, Claes1; Tran, Dzung D; Jere.Kapyaho@nokia.com;
> robin@robineko.com; jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]
> 
> 
> Hi,
> 
> I have to say that from a personal perspective I agree, although then we
> could get into an academic argument about what if we had a USB API and a
> sensor was connected via USB (but I won't go there).
> 
> 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.
> 
> 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?
> 
> Thanks,
> 
> 
> David.
> Director of External Relations, OMTP
> 
> -----Original Message-----
> From: public-device-apis-request@w3.org [mailto:public-device-apis-
> request@w3.org] On Behalf Of Nilsson, Claes1
> Sent: 06 October 2009 09:44
> To: 'Tran, Dzung D'; Jere.Kapyaho@nokia.com; robin@robineko.com;
> jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]
> 
> Thanks Jere for pointing at the earlier threads about sensors.
> 
> I agree that it will be difficult to specify a unique API for each type of
> sensor and that some kind of "generic" sensor API makes sense. That was
> what I meant by "universality".
> 
> Regards
>   Claes
> 
> -----Original Message-----
> From: Tran, Dzung D [mailto:dzung.d.tran@intel.com]
> Sent: måndag den 5 oktober 2009 18:34
> To: Jere.Kapyaho@nokia.com; Nilsson, Claes1; robin@robineko.com;
> jmcf@tid.es
> Cc: public-device-apis@w3.org
> Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]
> 
> It would be difficult to cover all the sensors ever made here, since new
> sensors come out all the time. Also, Geolocation is already a separate API
> and I consider Geolocation (GPS) is a sensor. I don't think it makes sense
> to have an API for each of type of sensor.
> 
> Maybe a separate overall sensor APIs makes sense?
> 
> 
> -----Original Message-----
> From: Jere.Kapyaho@nokia.com [mailto:Jere.Kapyaho@nokia.com]
> Sent: Monday, October 05, 2009 06:00 AM
> To: Claes1.Nilsson@sonyericsson.com; robin@robineko.com; jmcf@tid.es
> Cc: Tran, Dzung D; public-device-apis@w3.org
> Subject: Re: ISSUE-14: Gathering requirements [System Info & Events]
> 
> On 5.10.2009 15.46, "ext Nilsson, Claes1"
> <Claes1.Nilsson@sonyericsson.com>
> wrote:
> > I don't know if I am walking out of scope but I am considering "Personal
> > Metrics" within training and healthcare. For example we have personal
> pulse
> > watches, blood sugar sensors and blood pressure sensors. Web application
> > access to measurement data from that type of devices, either "built in"
> or
> > communicating with the device is needed. I guess that we can't predict
> all
> > types of information that we need to access so some kind of
> "universality"
> > would be useful within this context.
> 
> I think the operative word here is definitely "sensors", but thinking
> about
> it, I would keep APIs related to system information and related events
> separate from sensor input. I know that the lines tend to blur there, and
> I
> have certainly had many debates as to whether the battery charge indicator
> is a "sensor" just as an accelerometer (to give just a quick example). It
> depends on your view of the world, I guess. :-)
> 
> There's a start of a thread about sensors [1], and I know Robin cautiously
> opined [2] earlier that such would fit under System Information and Events.
> This could be the beginning of an interesting (and long, and maybe
> unnecessary) philosophical discussion, but in practical terms I'm simply
> concerned about lumping sensors with system events. From a developer's
> point
> of view a dedicated API for sensor data would probably be more palatable.
> 
> The argument for "universality" in API structure applies here as well as
> with system events, of course.
> 
> --Jere
> 
> [1] http://lists.w3.org/Archives/Public/public-device-

> apis/2009Aug/0049.html
> [2] http://lists.w3.org/Archives/Public/public-device-

> apis/2009Aug/0078.html
> 
>

Received on Friday, 9 October 2009 14:25:22 UTC