13:57:02 RRSAgent has joined #dap 13:57:02 logging to http://www.w3.org/2011/10/05-dap-irc 13:57:04 RRSAgent, make logs world 13:57:04 Zakim has joined #dap 13:57:06 Zakim, this will be DAP 13:57:06 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 3 minutes 13:57:07 Meeting: Device APIs Working Group Teleconference 13:57:07 Date: 05 October 2011 13:57:12 Agenda: /topic http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html 13:57:22 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html 13:58:08 Chair: Robin_Berjon, Frederick_Hirsch 13:58:11 Present+ Robin_Berjon, Frederick_Hirsch 13:58:47 rrsagent, generate minutes 13:58:47 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html fjh 13:58:53 zakim, code? 13:58:53 the conference code is 3279 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), fjh 13:59:23 s;Agenda: /topic http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0001.html;; 13:59:27 rrsagent, generate minutes 13:59:27 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html fjh 13:59:50 UW_DAP()10:00AM has now started 13:59:56 +SHayman 14:00:11 Claes has joined #dap 14:00:18 Dzung_Tran has joined #dap 14:00:24 AnssiK has joined #dap 14:00:34 Present+ Dzung_Tran 14:00:41 +??P28 14:00:47 + +34.63.888.aaaa 14:01:08 Clarke has joined #dap 14:01:13 +??P29 14:01:15 Zakim, ??P29 is me 14:01:15 +dom; got it 14:01:22 Present+ Dominique_Hazael-Massieux 14:01:27 Regrets+ Ernesto_Jimenez 14:01:30 Present+ Josh_Soref 14:01:34 Present+ Anssi_Kostiainen 14:01:35 Scribe Josh_Soref 14:01:36 Zakim, who's on the call? 14:01:36 On the phone I see Josh_Soref, ??P28, +34.63.888.aaaa, dom 14:01:37 + +46.1.08.01.aabb 14:01:42 +??P30 14:01:45 RRSAgent, make minutes 14:01:45 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html Josh_Soref 14:01:51 Zakim, ??P30 is me 14:01:51 +darobin; got it 14:02:00 + +1.503.380.aacc 14:02:09 Scribe: Josh_Soref 14:02:17 spoussa has joined #dap 14:02:17 Zakim, aabb is me 14:02:17 +Claes; got it 14:02:29 Present+ Claes_Nilsson 14:02:36 +??P34 14:02:43 zakim, ??P34 is me 14:02:43 +AnssiK; got it 14:02:48 wonsuk has joined #dap 14:02:51 +??P33 14:02:54 RRSAgent, make minutes 14:02:54 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html Josh_Soref 14:02:54 zakim, ?? is me 14:02:54 sorry, fjh, I do not recognize a party named '??' 14:03:01 jcantera has joined #dap 14:03:06 zakim, ??P33 is me 14:03:06 +fjh; got it 14:03:12 zakim, who is here? 14:03:12 On the phone I see Josh_Soref, ??P28, +34.63.888.aaaa, dom, Claes, darobin, +1.503.380.aacc, AnssiK, fjh 14:03:14 On IRC I see jcantera, wonsuk, spoussa, Clarke, AnssiK, Dzung_Tran, Claes, Zakim, RRSAgent, fjh, Josh_Soref, richt, darobin, wmaslowski_, ilkka, trackbot, dom 14:03:17 s/Scribe Josh_Soref// 14:03:27 Present+ Jose_Cantera 14:03:27 wmaslowski_ has left #dap 14:03:29 RRSAgent, make minutes 14:03:29 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html Josh_Soref 14:03:38 + +82.31.27.9.aadd 14:03:41 Present+ Clarke_Stevens 14:04:00 zakim, +82.31.27.9.aadd is me 14:04:00 +wonsuk; got it 14:04:09 Present+ Sakari_Poussa 14:04:13 Present+ Wonsuk_Lee 14:04:33 How do we know which number is us? 14:04:45 zakim, who is here? 14:04:45 On the phone I see Josh_Soref, ??P28, +34.63.888.aaaa, dom, Claes, darobin, +1.503.380.aacc, AnssiK, fjh, wonsuk 14:04:47 On IRC I see jcantera, wonsuk, spoussa, Clarke, AnssiK, Dzung_Tran, Claes, Zakim, RRSAgent, fjh, Josh_Soref, richt, darobin, ilkka, trackbot, dom 14:05:15 zakim, +34.63.888.aaaa is me 14:05:15 +jcantera; got it 14:06:10 zakim, ?? is clarke 14:06:10 +clarke; got it 14:06:26 + +1.503.542.aaee 14:06:28 Topic: Administrative 14:06:53 TPAC registration reminder, deadline 10 Oct hotel, 14 Oct registration, http://www.w3.org/wiki/TPAC2011 14:06:53 http://lists.w3.org/Archives/Member/member-device-apis/2011Sep/0003.html 14:06:56 fjh: TPAC registration deadline (fee increase) is coming shortly 14:07:06 questionnaire for noting remote attendance fixed, http://lists.w3.org/Archives/Member/member-device-apis/2011Oct/0000.html 14:07:08 zakim, aacc is spoussa 14:07:08 sorry, spoussa, I do not recognize a party named 'aacc' 14:07:16 q+ 14:07:24 ack Clarke 14:07:33 RRSAgent, make minutes 14:07:33 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html Josh_Soref 14:07:56 Clarke: this is my first TPAC... 14:07:58 ... Should i attend the TPAC Plenary? 14:08:17 fjh: there is an Unconference bit at the Plenary which could address JS API 14:08:26 darobin: in general attending the Plenary is useful 14:08:35 ... even if only for the social benefits 14:08:44 s/could address JS API/has session related to DAP architectural approach, JS API and REST/ 14:08:53 Topic: Minutes approval 14:09:00 http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/att-0134/minutes-2011-09-28.html 14:09:03 s/REST/HTTP-based APIs/ 14:09:13 RESOLUTION Minutes from 28 Sep are approved 14:09:28 Topic: Battery 14:09:40 fjh: there was a discussion of Battery on the TF mailing list 14:09:48 ... dom sent a message about it 14:09:57 q+ 14:09:59 [ Note that the Mailing list is not currently archiving correctly ] 14:10:02 ack AnssiK 14:10:05 ack AnssiK 14:10:09 AnssiK: please join the mailing list 14:10:18 [ indeed, Josh_Soref; I've asked for this to be fixed but haven't heard back yet] 14:10:23 s/that the/that the TF/ 14:10:40 ... otherwise we'd be forking the discussion 14:10:57 ... so we need to direct all discussion of Battery to that list 14:11:12 fjh: please sign up if you're interested so you don't miss that discussion 14:11:21 darobin: if you need help signing up, please contact me 14:11:26 Topic: Sensors 14:11:33 Draft, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0136.html (Jose) 14:11:33 comment, http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0138.html 14:11:36 fjh: I know Jose and dom sent emails 14:11:38 Zakim, who's on the call? 14:11:38 On the phone I see Josh_Soref, clarke, jcantera, dom, Claes, darobin, Sakari_Poussa, AnssiK, fjh, wonsuk, +1.503.542.aaee 14:11:38 zakim, who is here? 14:11:40 On the phone I see Josh_Soref, clarke, jcantera, dom, Claes, darobin, Sakari_Poussa, AnssiK, fjh, wonsuk, +1.503.542.aaee 14:11:43 On IRC I see jcantera, wonsuk, spoussa, Clarke, AnssiK, Dzung_Tran, Claes, Zakim, RRSAgent, fjh, Josh_Soref, richt, darobin, ilkka, trackbot, dom 14:11:51 Zakim, aaee is probably Dzung 14:11:51 +Dzung?; got it 14:12:19 Dzung_Tran: There's work to be done esp. with Timestamp and Accuracy 14:12:31 ... I'll check something in this week 14:12:33 welcome jose to DAP, jose 14:12:48 jcantera: We're also thinking on the XXX issue 14:13:08 s/XXX issue/discovery of sensors available 14:13:24 ... using this approach you could cover discovery 14:13:33 ... [ under sensors ? ] 14:13:38 q+ 14:13:46 ack Claes 14:14:00 fjh_ has joined #dap 14:14:01 q+ dom 14:14:26 Claes: I'm glad that Discovery is continuing 14:14:37 ... have you discovered the scope of where sensors can exist? 14:14:44 ... sensors can be internal to the device 14:14:50 ... or connected 14:14:53 ... or in the local network 14:14:58 ... or they can be in the cloud 14:15:05 jcantera: the idea is to have a method 14:15:11 ... for example listSensors 14:15:16 ... and you can provide a type of sensor 14:15:26 ... which would return a reference to a sensor of that type 14:15:40 ... if the listSensors implementation can detect a sensor in the environment 14:15:52 ... then you could get access to a device that isn't within the device per se 14:16:02 ... this approach covers the Discovery use case 14:16:11 ... the other approach would be to have some binding between Sensors 14:16:15 ... and Discovery. 14:16:25 ... That path could delay Sensors. 14:16:37 RRSAgent, make minutes 14:16:37 I have made the request to generate http://www.w3.org/2011/10/05-dap-minutes.html Josh_Soref 14:16:58 Claes: I can understand making Sensors not depend on another specification 14:17:03 ... I sent a mail to the task list 14:17:17 ... where I provide information about the Webinos API and Discover 14:18:10 jcantera: Leaving things separated between Sensors and Discovery 14:18:35 ... where Discovery returns something which could then be used by Sensors 14:18:48 ... [ is possible ] 14:18:54 ... I'll send an updated proposal 14:18:56 q+ 14:19:26 Claes: another issue was needing to expose a method for 14:19:48 ... details about the discovered sensor 14:20:01 ... there are use cases where a web application wants to be tailored to a specific sensor 14:20:03 q+ to object 14:20:24 q? 14:20:26 ... this sort of information is exposed by Android 14:20:41 jcantera: Yes, I understand there are interesting attributes available from the platform 14:20:56 ... we could for example have something in the api for sensor metadata 14:22:24 s/mail to the task list/mail to the mailing list/ 14:22:29 ack dom 14:22:45 http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0004.html 14:22:52 dom: To reiterate my suggestion 14:22:56 +1 14:23:08 ... we should remove the part of the Sensor api that overlaps with the DeviceOrientation spec 14:23:15 +1 to remove overlapping parts 14:23:27 jcantera: Should we have the Sensor API agnostic to the data types it provides? 14:23:39 ... or just have it drop the conflicting bits? 14:23:50 dom: my suggestion is simply dropping the overlap 14:24:02 ... if we see value in generic data types, we can do that 14:24:14 ... but for now, we should start with more concrete items and avoid the overlap 14:24:29 darobin: we also see some value in more lower level bits than provided by the Orientation spec 14:24:45 ... for that, it would be valuable to discuss that with the GeoLocation WG 14:24:49 ... which manages that spec 14:25:05 jcantera: I agree with dom, that we should avoid confusion/conflict with other groups/specs 14:25:32 ... from a technical perspective, DeviceMotion is not targeted to get Raw Sensor Data 14:25:47 ... it's designed to get general motion 14:25:58 ... which involves removing Noise and other stuff 14:25:59 (I'm fairly sure that at least Firefox sends raw data for devicemotion) 14:26:00 +1 avoid overlap 14:26:15 [it's worth finding out] 14:26:22 ... You also can't control the precision, resolution, or time intervals 14:26:31 [this sounds like good feedback to send to the Geo WG :) ] 14:26:55 ... Could we contact the Editors of that spec about this? 14:27:03 dom: I'd suggest you send feedback to their mailing list 14:27:15 ... I'm not sure they've fully considered them 14:27:29 ... I agree these considerations need to be discussed 14:27:40 q? 14:27:44 darobin: it's especially important to give them use cases for providing Raw information 14:27:50 jcantera: One of the use cases is Games 14:28:00 ... in Games, you need to have a good rate of delivery of sensor data 14:28:02 q+ 14:28:14 ... otherwise the game will not be "responsive" 14:28:22 ack Clarke 14:28:32 Clarke: My question is about Scope 14:28:43 ... there seems to be a specific type of Sensor, covered here 14:28:48 ... things relating to Context... 14:28:53 ... things you'd find in a mobile phone 14:29:13 ... in other groups I'm in, we're looking at more a broad scope 14:29:27 ... things like Burglar alarms, Fire alarms, Temperature, ... 14:29:42 ... If we aren't looking at that, we should make a note that they're things which we could look at in the future 14:29:50 +1 for Clarke's comment 14:29:52 jcantera: We have left the API open to deal with new data types 14:30:08 ... the spec has defined a vocabulary of sensors 14:30:14 ... but it isn't closed to new sensors 14:30:28 ... Concerning discovery, 14:30:48 ... let's have an API that can work seemlessly with Discovery 14:31:00 ... Or have a simple mechanism to support simple Discovery 14:31:13 q+ to ask where the "sensor:" prefix comes from and if we can just kill it 14:31:18 ... give me whatever Sensors are in the Environment and then I will query them 14:31:51 +1 to darobin's proposal to not have useless prefixes/things that look like schemes 14:32:09 Clarke: I agree with focusing on a subset of usecases 14:32:28 ... if we're going to have a Sensor api that's general enough to cover sensors that are included in other specifications 14:32:33 .... Do we want to include Actuators? 14:32:46 jcantera: Actuators being things where we can set values? 14:32:50 are we having scope creep here? 14:32:57 Clarke: Right, setting values on a Thermostat, or Ringing a bell 14:33:06 jcantera: That wasn't initially in the scope 14:33:17 Clarke: I just want to be clear on the scope 14:33:27 q? 14:33:33 I think we should do that later 14:33:33 +1 to start with a limited scope (local sensors) 14:33:39 +1 indeed 14:33:48 ack josh_soref 14:33:48 Josh_Soref, you wanted to object 14:34:09 [I think that if we have a decent model to expose sensor data for local sensors, it should be easily adapted to expose remote sensors] 14:34:39 josh_soref: want interop between various sensors and applications as consumer 14:35:38 josh_soref: concern about vendor name and model details 14:36:10 Zakim: mute me 14:36:19 Zakim, mute me 14:36:19 Josh_Soref should now be muted 14:36:24 s/Zakim: mute me// 14:36:45 Clarke: Let's say that I want to customize my application to details from a specific sensor 14:36:49 q+ to respond 14:37:09 Zakim, unmute me 14:37:09 Josh_Soref should no longer be muted 14:37:15 ack me 14:37:15 Josh_Soref, you wanted to respond 14:38:11 Josh_Soref: a long time ago a browser was called Mozilla, people started UA sniffing for it, and now all browsers are identified as Mozilla 14:38:31 josh_soref: concern about analogy web browser sniffing for features, only work with specific browser etc 14:39:28 Josh_Soref: providing brand, etc. information is not beneficial to anyone 14:39:34 contract this against feature detection (good) vs. navigator.userAgent sniffing (bad) 14:39:42 s/contract/contrast/ 14:40:11 Clarke: if you expose the data/attributes in a standardized way 14:40:23 ... and you also have a textual name of your company 14:40:25 ... is that ok? 14:40:34 ... or should you be forbidden to expose the name of your company? 14:40:36 I don't see a use for it 14:41:09 so what you are saying is that if you don't convey company/product identity information then requiring a specific company/product for feature can be prevented 14:41:48 clarke: this eliminates some branding 14:41:55 -Dzung? 14:41:57 q? 14:42:05 josh_soref: branding at this level doesn't matter 14:42:45 Josh_Soref: it's true that vendor information exists at lower levels, but those should only really be relevant at most at the Device Driver layer 14:42:57 Clarke: I have one use case which is legitimate for branding 14:43:06 ... Say I have 3 printers available 14:43:15 ... As a user, having those names available is useful to me 14:43:20 darobin: I agree there's a use case for that 14:43:37 q+ to note that the UA can let the user see this without exposing it to web apps 14:44:00 ... I suspect that we'll be more successful 14:44:03 ... if we XX2 14:44:04 q? 14:44:19 ... Recommend that services not rely on brand names 14:44:39 ack Claes 14:44:44 Clarke: I hope that textual information isn't a big concern 14:44:48 s/XX2/let people add the brand info they want to, and recommend that developers rely on feature detection for most cases, which is a known best practice/ 14:45:06 [ note that UserAgents are Textual Information, as was the iPod-iTunes vendor ID , and they were both heavily abused ] 14:45:29 Claes: I'd like to ensure that there are at least locally connected devices 14:45:46 have a SHOULD NOT use brand info for feature detection?? 14:45:48 ... I agree that we shouldn't duplicate other existing devices 14:46:18 q? 14:46:22 ack me 14:46:22 darobin, you wanted to ask where the "sensor:" prefix comes from and if we can just kill it 14:46:35 Claes: For demo purposes, DeviceOrientation is a good demo 14:46:48 ... even though it shouldn't necessarily something that should be included in the end 14:47:02 darobin: concerning the sensor api 14:47:13 ... I was wondering where the 'sensor:' prefix comes from 14:47:17 ... and if it's really useful 14:47:25 +1 ; the SensorConnection() constructor already serves as namespacing for events 14:47:29 ... i think 'temperature' is better than 'sensor:temperature' 14:47:39 jcantera: the intention initially was to have a URI for sensors 14:47:45 darobin: do you think that's actually useful? 14:48:18 jcantera: if you could do 14:48:23 s/instant/instance/ 14:48:31 -1 on URI for specific sensors 14:48:49 ... you could have specific refrences that you could individually reference 14:49:01 darobin: wouldn't it be simpler to just pass parameters to a constructor? 14:49:06 new SensorConnection("temperature", { name: foo }) vs new SensorConnection("sensortemperature/" + foo); 14:49:32 s/name: foo/name: "foo"/ 14:49:41 jcantera: you prefer not to have a URI? 14:49:43 darobin: yes 14:49:58 jcantera: ok, I agree, that can be dropped 14:49:59 s/name: "foo"/name: foo/ 14:50:10 s/sensortemperature/sensor:temperature/ 14:50:28 darobin: it's a bit dodgy to have a URI you can't use in the URL bar 14:50:32 ... or link to 14:50:32 q? 14:50:33 ... etc. 14:50:33 q? 14:50:38 ack me 14:50:38 Josh_Soref, you wanted to note that the UA can let the user see this without exposing it to web apps 14:51:08 +1 for start simple — add complexity when use cases come in 14:51:24 dom: the question of how do you keep track of single sensors vs. multiple sensors 14:51:27 ... requires more thinking 14:51:32 ... and should be addressed later 14:51:42 darobin: should we have an issue about Single v. Multiple sensors? 14:51:59 ISSUE: How to handle exposing single vs multiple sensors of the same type 14:51:59 Created ISSUE-120 - How to handle exposing single vs multiple sensors of the same type ; please complete additional details at http://www.w3.org/2009/dap/track/issues/120/edit . 14:52:04 q? 14:52:37 ack me 14:52:37 darobin, you wanted to say blah blah 14:53:11 josh_soref: about use case of picking printer, this is essential for multiple sensor use case 14:53:32 ... once user picks sensor then app doesn't need branding info 14:55:03 +1 for UA to be a broker for selecting sensors (but that needs refinement) 14:55:08 ... suggests ua exposes information selectively depending on whether discovery or not 14:55:23 darobin: proposals to the mailing list would be appreciated 14:55:31 ... someone could take an action item 14:55:53 ACTION: Josh to write to the list to explain UA mediation in selecting sensors 14:55:54 Created ACTION-456 - Write to the list to explain UA mediation in selecting sensors [on Josh Soref - due 2011-10-12]. 14:56:04 q? 14:56:15 Topic: Discovery 14:56:26 fjh: well, this was covered in Sensors ... 14:56:27 http://lists.w3.org/Archives/Public/public-device-apis/2011Sep/0141.html 14:56:32 -jcantera 14:56:36 q+ to ask how do we move forward? 14:56:41 s/covered/touched on / 14:56:43 btw. thanks Claes for updating http://www.w3.org/2009/dap/wiki/ServiceDiscoveryComparison 14:56:51 s/Sensors/Sensors discussion/ 14:57:08 +1 thanks to Claes for the comparison wiki page 14:57:09 Claes: there will be a post to the list on Use Cases 14:57:32 q- 14:57:38 Clarke: i think the next step is to try to consolidate them 14:57:56 ... our goal is to determine which use cases can't be covered with current specs 14:58:07 q? 14:58:09 ... If we could work the Webinos use cases into that, that would be great 14:58:15 Claes: We're working on that 14:58:26 ... and hopefully we can talk more about that next week 14:58:30 zakim, who is here? 14:58:31 On the phone I see Josh_Soref, clarke, dom, Claes, darobin, Sakari_Poussa, AnssiK, fjh, wonsuk 14:58:36 darobin: any volunteers to start editing a document? 14:58:37 On IRC I see fjh, jcantera, wonsuk, spoussa, Clarke, AnssiK, Claes, Zakim, RRSAgent, Josh_Soref, richt, darobin, ilkka, trackbot, dom 14:58:50 Clarke: we've already created a document 14:58:51 link? 14:59:25 http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases 14:59:25 http://www.w3.org/2009/dap/wiki/ServiceDiscoveryUseCases 14:59:56 Clarke: if you want to edit that wiki, please contribute, especially for consolidation 15:00:14 darobin: that's a good first step 15:00:29 ... the next step would be to try to draft something into a spec 15:00:33 ... but is this too early? 15:00:41 Clarke: the spec that Opera and Cable Labs are submitting 15:00:49 ... is based on the w3 requirements listed here 15:01:07 [ time check - we're over ] 15:01:30 darobin: if people from Webinos are comfortable, i'd like to encourage a draft be put into cvs/Hg 15:01:34 ... objections? 15:01:55 Claes: i'd rather we wait a week, i think we need to have a bit more discussion 15:02:37 s/over/past the 1 hour mark -- which is well over our recent average/ 15:02:51 darobin: anything else on our agenda for Discovery? 15:02:52 [ no ] 15:02:58 -clarke 15:02:59 Topic: TPAC Agenda 15:03:03 http://www.w3.org/2009/dap/wiki/F2F_Agenda_3-4_November_2011,_Santa_Clara_%28TPAC%29 15:03:37 http://lists.w3.org/Archives/Public/public-device-apis/2011Oct/0010.html 15:03:56 fjh: we have to join with MediaCapture, WebRTC and TAG 15:04:03 ... for Joint Meetings 15:04:13 ... I'm not sure what to do with HTML Media Capture 15:04:22 darobin: I don't know that a joint meeting with the HTML WG would be useful 15:04:52 fjh: WebRTC seems more important 15:05:18 darobin: TAG will be a discussion about HTTP based APIs 15:05:25 s/seems more important/would be useful/ 15:05:26 fjh: it's really one or two people joining us 15:05:39 darobin: don't hesitate to edit the Wiki 15:05:46 ... add topics to the Top 15:05:48 TAG is having architectural item on its agenda this week 15:06:07 ... if you have preferences for times (because of conflicts or you're calling in), certainly tell us 15:06:11 .... we'll try to work that in 15:06:21 darobin: questions on the TPAC agenda? 15:06:26 Topic: AoB 15:06:31 s/we have to join with MediaCapture, WebRTC and TAG/he suggested next steps for HTML Media Capture, WebRTC and TAG/ 15:06:35 s/AoB/AOB/ 15:07:02 -dom 15:07:03 -fjh 15:07:05 -darobin 15:07:10