14:27:28 RRSAgent has joined #dap 14:27:28 logging to http://www.w3.org/2014/11/13-dap-irc 14:27:30 RRSAgent, make logs world 14:27:30 Zakim has joined #dap 14:27:32 Zakim, this will be DAP 14:27:32 ok, trackbot; I see UW_DAP()10:00AM scheduled to start in 33 minutes 14:27:33 Meeting: Device APIs Working Group Teleconference 14:27:33 Date: 13 November 2014 14:27:49 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Oct/0033.html 14:27:59 fjh_ has changed the topic to: dap 3279; agenda http://lists.w3.org/Archives/Public/public-device-apis/2014Oct/0033.html 14:28:18 Chair: Frederick_Hirsch 14:28:24 Present+ Frederick_Hirsch 14:28:42 Regrets+ Dominique_Hazael-Massieux 14:46:11 Present+ Anssi_Kostiainen 14:46:53 Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0014.html 14:46:58 fjh_ has changed the topic to: dap 3279; agenda http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0014.html 14:48:05 Louay has joined #dap 14:50:21 UW_DAP()10:00AM has now started 14:50:28 +??P0 14:50:31 zakim, ??P0 is me 14:50:31 +anssik; got it 14:52:14 +[IPcaller] 14:52:23 zakim, ipcaller is me 14:52:23 +fjh_; got it 14:53:43 + +1.206.734.aaaa 14:54:36 dom has joined #dap 14:55:06 PaulBoyes has joined #dap 14:55:17 zakim, who is here? 14:55:17 On the phone I see anssik, fjh_, +1.206.734.aaaa 14:55:18 On IRC I see PaulBoyes, dom, Louay, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, trackbot 14:55:34 zakim, aaaa is PaulBoyes 14:55:34 +PaulBoyes; got it 14:55:45 Paul Boyes - Co-Chair Automotive BG 14:55:46 gmandyam has joined #dap 14:55:52 Zakim, code? 14:55:52 the conference code is 3279 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dom 14:56:07 +??P3 14:56:13 Zakim, ??P3 is me 14:56:13 +dom; got it 14:56:42 rkawada has joined #dap 14:56:54 Present+ Mats_Wichmann 14:57:20 +gmandyam 14:57:28 +??P5 14:57:45 Zakim, ??P5 is mats 14:57:45 +mats; got it 14:58:19 -dom 14:58:26 Zakim, call dom-mobile 14:58:26 ok, dom; the call is being made 14:58:28 +Dom 14:58:30 Present+ Tobie_Langel 14:58:45 Present+ Dominique_Hazael-Massieux 14:58:53 zakim, who is here? 14:58:53 On the phone I see anssik, fjh_, PaulBoyes, gmandyam, mats, Dom (muted) 14:58:55 On IRC I see rkawada, gmandyam, PaulBoyes, dom, Louay, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, trackbot 14:59:13 Zakim, drop dom 14:59:13 Dom is being disconnected 14:59:14 -Dom 14:59:18 Zakim, call dom-mobile 14:59:18 ok, dom; the call is being made 14:59:20 +Dom 15:00:09 ted has joined #dap 15:00:17 agenda? 15:00:20 Regrets- Dominique_Hazael-Massieux 15:00:38 Present+ Dominique_Hazael-Massieux 15:00:53 zakim, who is here? 15:00:54 On the phone I see anssik, fjh_, PaulBoyes, gmandyam, mats, Dom 15:00:54 On IRC I see ted, rkawada, gmandyam, PaulBoyes, dom, Louay, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, trackbot 15:01:32 +[IPcaller] 15:01:32 Guest52 has joined #dap 15:01:50 + +44.207.184.aabb 15:01:53 Zakim, [ is me 15:01:53 +tobie; got it 15:01:54 zakim, ipcaller is tobie 15:01:55 sorry, fjh_, I do not recognize a party named 'ipcaller' 15:02:09 zakim, aabb is mounir 15:02:10 +mounir; got it 15:02:26 Good morning and afternoon 15:02:31 +[IPcaller] 15:02:37 Present+ Mounir_Lamouri, Tobie_Langel 15:02:46 Present+ Rich_Tibbett 15:02:53 +??P16 15:02:55 zakim, who is here? 15:02:55 On the phone I see anssik, fjh_, PaulBoyes, gmandyam, mats, Dom, tobie, mounir, richt, ??P16 15:02:57 On IRC I see rwaldron, ted, rkawada, gmandyam, PaulBoyes, dom, Louay, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, trackbot 15:02:57 +??P17 15:03:05 zakim, ??P16 is me 15:03:05 I already had ??P16 as ted, rkawada 15:03:16 Zakim, ??P17 is rkawada 15:03:16 +rkawada; got it 15:03:27 Present+ Ted_Guild 15:03:45 + +1.857.540.aacc 15:03:52 scribenick: mounir 15:04:16 zakim, where is 857? 15:04:16 North American dialing code 1.857 is Massachusetts 15:04:36 mounir: I'm going to describe Tim's proposal 15:04:38 Zakim, aacc is rwaldron 15:04:38 +rwaldron; got it 15:04:43 Present+ Rick_Waldron 15:05:13 Claes has joined #dap 15:05:20 Topic: Welcome, agenda review, scribe selection, announcements, status updates 15:05:27 wake lock status - http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0010.html 15:05:28 health care TPAC breakout summary - http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0007.html 15:05:33 -anssik 15:05:54 Louay_ has joined #dap 15:06:18 Yes 15:06:18 +??P0 15:06:20 zakim, who is here? 15:06:20 On the phone I see fjh_, PaulBoyes, gmandyam, mats, Dom, tobie, mounir, richt, ted (muted), rkawada, rwaldron, ??P0 15:06:22 On IRC I see Louay_, Claes, rwaldron, ted, rkawada, gmandyam, PaulBoyes, dom, Louay, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, 15:06:23 ... trackbot 15:06:23 zakim, ??P0 is me 15:06:25 +anssik; got it 15:06:29 I am 15:06:54 fjh_: we had a breakout session about sensors api 15:06:57 ... there is a lot of interest 15:07:13 ... there is an IG and a desire to work on this 15:07:27 Topic: Battery API 15:07:34 CfC for transitioning and publishing Battery API as CR completed successfully, http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0012.html 15:07:38 fjh_: I want to summarize quickly about battery 15:07:44 Topic: Vibration API 15:07:50 CfC for transitioning and publishing Vibration API as PR completed successfully, http://lists.w3.org/Archives/Public/public-device-apis/2014Nov/0013.html 15:07:53 ... the CfC has concluded and Anssi will create a CR 15:08:03 Topic: Minutes approval 15:08:06 ... same for Vibration API 15:08:11 Approve minutes from 2 October 2014 15:08:19 http://lists.w3.org/Archives/Public/public-device-apis/2014Oct/att-0003/minutes-2014-10-02.html 15:08:24 RESOLUTION: Minutes from 2 October 2014 are approved 15:08:36 + +49.303.463.aadd 15:08:37 Topic: Generic Sensor API: Context, problem statement, goals 15:09:17 + +46.7.03.79.aaee 15:09:28 https://www.w3.org/wiki/TPAC2014/SessionIdeas#Generic_Sensor_API -> TPAC breakout session “Generic Sensor API” 15:09:30 anssik: we meant to talk about generic sensors at TPAC but many folks 15:09:37 ... were not present at the TPAC meeting 15:09:48 Present+ Claes_Nilsson 15:10:00 anssik: we have numerous sensors exposed to the Web platform 15:10:04 ... 15:10:05 A number of sensors are already exposed to the Web Platform (e.g. Geolocation, Device Orientation) and new sensors are on their way (e.g. Ambient Light). 15:10:26 Current status of sensor APIs on the Web Platform: 15:10:26 http://www.w3.org/Mobile/mobile-web-app-state/#Sensors_and_hardware_integration -> W3C Sensors Roadmap 15:10:33 anssik: a good summary can be found in a document dom has been working on 15:11:02 Also more experimental work in the pipeline, such as domain-specific sensors: automotive, health care 15:11:05 anssik: in addition, there is more experimental work in the pipeline 15:11:30 anssik: there is currently no established defined pattern 15:11:31 No established design pattern that is a particularly good fit for sensor APIs on the Web Platform 15:11:58 Current sensor APIs on the Web are high-level, abstract away details 15:12:57 The Node.js community has defined and implemented lower-level composable APIs for exposing new sensors 15:13:05 Zakim, aaee is Claes 15:13:05 +Claes; got it 15:13:07 https://github.com/rwaldron/johnny-five#sensors -> johnny-five Sensors 15:13:19 Problem statement 15:13:43 Proliferation of sensor APIs on the Web Platform + lack of applicable design patterns and best practices = suboptimal and inconsistent APIs 15:13:58 More specifically 15:14:06 Zakim, aadd is @@_from_Fraunhofer 15:14:06 +@@_from_Fraunhofer; got it 15:14:16 New use cases and requirements unaddressed by the current high-level APIs 15:14:18 suboptimal in which way? 15:14:37 [@@_from_Fraunhofer might be Christian Fuhrhop] 15:14:56 New requirements likely cannot be addressed by incremental improvements (“v2”) due to different level of abstraction -- layered design to rescue? 15:15:11 Lack of consistency leading to web developer ergonomics issues 15:15:15 q+ to ask about criteria 15:15:49 Webinos project already worked on a spec for Generic Sensor and Actuator API http://dev.webinos.org/specifications/api/sensors.html 15:16:23 Known issues overview 15:16:55 Since we now have web developer feedback and validation we can do data-driven API design 15:17:19 Known issues shared with all sensor APIs that define a new DOM event type (DeviceOrientationEvent, DeviceMotionEvent, DeviceLightEvent, DeviceProximityEvent etc.): 15:17:36 1) Unable to retrieve a sensor reading at any time 15:17:44 q- 15:18:11 https://bugzil.la/1057185 -> Moz bug 1057185 15:18:31 http://www.w3.org/2009/dap/track/issues/170 -> W3C spec issue re Moz bug 1057185 15:18:46 q+ 15:18:56 ack gmandyam 15:18:57 ack gmandyam 15:19:16 zakim, who is here? 15:19:16 On the phone I see fjh_, PaulBoyes, gmandyam, mats, Dom, tobie, mounir, richt, ted (muted), rkawada, rwaldron, anssik, @@_from_Fraunhofer, Claes 15:19:18 On IRC I see Louay_, Claes, rwaldron, ted, rkawada, gmandyam, PaulBoyes, dom, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, trackbot 15:19:52 Present+ Giri_Mandyam 15:20:35 gmandyam: issue 1) not affecting Geolocation API 15:20:51 gmandyam notes it is an API sensor design issue, not a motivation for generic sensor 15:20:59 q? 15:21:08 2) Limited to a single sensor of each type 15:21:30 -anssik 15:21:36 https://extensiblewebreportcard.org/ -> issue noted by TAG, see “Sensors” 15:22:18 +??P0 15:22:27 zakim, ??P0 is me 15:22:27 +anssik; got it 15:23:07 Geolocation has getCurrentPosition, and watchPosition is supposed to return a Position object if successfully invoked. Mozilla bug 1057185 is not a generic sensor API problem, but one due to design choices of Ambient Light 15:23:23 3) Sensors in loop-based situations (use cases: games, accelerometer-based scrolling, augmented reality) 15:23:35 https://github.com/rwaldron/sensors/issues/5 -> Provide a way of tying sensor requests to animation frames 15:24:04 q+ to mention slowness of implementing and deploying new sensor apis (ties to #2 above) 15:24:17 due to events? 15:24:36 q? 15:24:38 ack tobie 15:24:38 tobie, you wanted to mention slowness of implementing and deploying new sensor apis (ties to #2 above) 15:24:42 anssik says yes 15:24:55 ack tobie 15:25:10 tobie: takes a lot of time to introduce a new sensor 15:25:18 ... implement in browsers 15:25:41 tobie notes that time to market for new sensors impacted by not having generic sensor api, due to more time for specs, etc 15:26:53 mounir: I think experimentation is slightly out of topic, it's not specific to sensors 15:26:54 4) Sensor frequency not developer configurable 15:27:07 ... but is more generic to the web platform even though it tends 15:27:13 ... to be a bigger problem for hardware-related apis 15:27:24 5) Threshold (min/max) not developer configurable 15:27:26 mounir: There are a few ideas around like the api keys proposed 15:27:43 ... by Microsoft at TPAC and discussed at BlinkOn and also 15:27:55 ... navigator.connect() that has some shared goals 15:27:57 Tying sensor API's to requestAnimationFrame is one issue. But is a general sensor API needed that operates like requestAnimationFrame? For instance, requestSensorData which only invokes the successCallback when the sensor is ready to provide new data? 15:28:00 6) Dependency on the window object or other web related concepts 15:28:40 cannot be exposed to background processing (ServiceWorkerGlobalScope) or other window-less contexts (e.g. Node.js global) 15:29:26 Developer requesting sensor frequency may be OK, as long as they are not mandatory. Implementations may modulate the sensor frequency depending on the function (e.g. geofencing, where location polling frequency is adjusted based on distance from virtual geofence) 15:29:45 To draw parallels, WHATWG Streams is currently agnostic to the environment, implementable in the browser and Node.js environments. 15:30:22 W3C Streams API extends the WHATWG spec to meet the requirements specific to the browser environment. 15:31:11 Can we do something similar and agree on the right level of abstraction for a low-level API (“generic sensor API”) that enables high-level APIs as polyfills? 15:31:22 idea of base multi-purpose spec with vertical specific specs above it might tie into discussion from TPAC health care discussion 15:31:52 q+ to ask about testing, progressing generic api 15:32:03 ack fjh_ 15:32:03 fjh_, you wanted to ask about testing, progressing generic api 15:32:32 Topic: Generic Sensor API: Related work in W3C, current status 15:32:32 fjh_: in DAP, we explicitely decided to do small specifications that can evolve quickly 15:32:47 fjh_: how to do testing 15:32:51 ... with a generic sensor API, how do you know it does work given that it is generic? 15:33:58 q+ 15:34:13 mounir notes could create Note for basis then create specs that are testable using it 15:34:14 DAP work on sensors; see http://www.w3.org/2009/dap/wiki/SingleSensorSpecification 15:34:14 q- 15:34:15 mounir: a generic sensor api is meant to be a pattern, not something to publish, implement and test 15:34:30 thanks, that answers the question 15:34:54 gmandyam: met at TPAC, richt, Tim attended, we looked at DeviceOrientation 15:35:03 scribenick: anssik 15:35:05 ... that is a problematic spec 15:35:24 ... the spec implemented in four browsers 15:35:46 ... changes to implementations is hard 15:36:20 ... re Geolocation, we're adding Geofencing exposed to ServiceWorkerGlobalScope 15:36:28 q+ on polyfilling existing APIs 15:36:31 ... that seems complementary 15:36:57 ... people pointed at the TPAC why Geolocation WG was separate 15:37:08 s/pointed/pointed out/ 15:37:43 q? 15:37:45 -anssik 15:37:46 ack tobie 15:37:46 tobie, you wanted to comment on polyfilling existing APIs 15:38:22 +??P0 15:38:25 zakim, ??P0 is me 15:38:25 +anssik; got it 15:38:42 Geolocation: the Geo WG met at the recent TPAC and took up the issues regarding DeviceOrientation: minutes are in http://www.w3.org/2014/10/27-28-geolocation-minutes.html 15:38:52 tobie: it is important, when designing a generic sensor API, to be able to polyfill existing APIs 15:39:16 q? 15:39:21 Topic: Generic Sensor API Proposal review - Sensor API Unification Sketch 15:39:40 fjh: as long as this does not harm new API design, to the extent possible 15:39:50 https://github.com/rwaldron/sensors 15:40:01 https://github.com/rwaldron/sensors -> Sensor API Unification Sketch 15:40:14 Geolocation (cont.): Tim Volodine (Google) presented how DeviceOrientation can be adapted in the context of a generic Sensor API: https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf 15:40:25 rwaldon: has been working over two yours on johnny-five framework 15:40:46 ... it is a Node.js framework that enables easily to write programs that interact with hardware 15:40:51 ... started with client and host model 15:41:00 ... communication over serial, like Arduino 15:41:16 ... turning those things into sensor terminals 15:41:45 ... aim to come up with sensors that are as intuitive as possible 15:41:59 ... works with platforms that have GPIO etc. interfaces 15:42:36 ... centers around creating a generic sensor instance from a sensor constructor that derives its data from the underlying platform 15:42:49 ... currently active 15:42:58 ... what this means for browsers 15:43:15 ... it doesn't make sense to have a dependency on window 15:43:28 ... or navigator object 15:43:41 ... both of these objects are inppropriate homes for sensors 15:44:15 ... effectively these are stand alone constructors that allow creating N number of instances 15:44:24 ... for example, I have temperature sensor in my phone 15:44:33 ... I should not need to wait for the event to arrive on the window 15:44:37 or navigator 15:44:54 rwaldron: or promise 15:45:14 ... I should have a mechanism to command the frequency of the sensor 15:45:17 -Dom 15:45:23 ... including a change event 15:46:24 ... agree with tobie that Tim's proposal is very similar to ours (Rick, Tobie, Domenic) 15:46:50 ... but our proposal does not have dependency web related concepts such as window, navigator 15:47:03 https://github.com/rwaldron/sensors -> Sensor API Unification Sketch 15:47:37 ... device orientation and some others have landed as implementation in browsers 15:47:51 ... however, if we make the existing sensor APIs slightly lower-level 15:48:27 -rwaldron 15:48:33 q+ to ask if/how this proposal enables feature detection 15:48:34 ... we'd be giving future developers better APIs 15:48:41 redialing 15:49:19 +rwaldron 15:49:54 ... tobie and Domenic have more to say 15:49:58 q? 15:50:01 q+ 15:50:03 ack richt 15:50:03 richt, you wanted to ask if/how this proposal enables feature detection 15:50:19 richt: how to enable feature detection? 15:50:53 rwaldron: if a browser support the sensor, the sensor constructor will exists, otherwise not 15:51:18 richt: implementers haven't done that in browsers, that is the current problem 15:51:46 ... the pushback as been, you'll need to ask the platform to make sure 15:52:05 rwaldron: secondary mechanism, .value would be null if no sensor exists 15:52:14 ... a normative requirement for the specification 15:52:41 q+ on feature detection 15:52:45 ... we request a promise, of .value does not have a value the sensor is not supported 15:52:47 q? 15:53:28 DeviceOrientation feature detection in this model has been a problem (https://github.com/w3c/deviceorientation/pull/12). 15:53:44 -anssik 15:53:45 zakim, who is here? 15:53:45 On the phone I see fjh_, PaulBoyes, gmandyam, mats, tobie, mounir, richt, ted (muted), rkawada, @@_from_Fraunhofer, Claes, rwaldron 15:53:48 On IRC I see Louay_, Claes, rwaldron, ted, rkawada, gmandyam, PaulBoyes, Zakim, RRSAgent, mats, fjh_, anssik, fjh, mounir, slightlyoff, tobie, richt, Josh_Soref, trackbot 15:54:15 +??P3 15:54:22 zakim, ??P3 is me 15:54:22 +anssik; got it 15:54:32 rwaldron: cannot have value unless support reading from sensors 15:54:56 q? 15:56:07 ack mounir 15:56:33 mounir: not a use case, marcos had the same comment 15:56:44 q? 15:56:47 ... Node.js environment is different in this regard 15:56:51 q+ 15:56:55 ack rwaldron 15:57:04 q? 15:57:51 q+ 15:57:59 mounir: browsers have more constraints than Node.js 15:57:59 group notes node.js offers insight but not necessarily the use case 15:58:05 q? 15:58:09 q? 15:58:38 ack tobie 15:58:38 tobie, you wanted to comment on feature detection 15:59:12 tobie: feature detection is worth discussing on the mailing list 15:59:22 +1 15:59:25 ... would invite richt 15:59:36 q? 15:59:47 q? 15:59:51 q- rwaldron 16:00:23 rwaldron: not an attempt to push a specific API e.g. johnny-five's design on Web 16:00:33 ... just want to share learnings from other context 16:00:43 Topic: Generic Sensor API Proposal review - Tim Volodine's proposal 16:01:07 http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0024.html 16:01:17 mounir: the main difference to Rick's is that when Tim and I looked at how to make a better sensor API 16:01:34 ... first, DeviceOrientation can be only accessed through event 16:01:50 Present+ ??_from_Fraunhofer 16:01:55 ... with Rick's proposal you have .value which may or may not return a value 16:02:01 q+ 16:02:07 ... in Tim's proposal, the value is always a real value 16:02:17 ... since it is gated behind a promise 16:02:27 q? 16:02:37 q+ 16:03:26 ... other details like hanging off of navigator, we could move elsewhere 16:03:40 ... such as fooSensor.getXXX 16:03:42 mounir: rejected if not available so not even aware there is no sensor, might be positive for privacy 16:04:15 ... discussed at TPAC, maybe we should be more clever in how we handle frequency 16:04:27 http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0024.html 16:05:15 mounir: the mail is the canonical public source 16:05:24 ... will look for a better pointer 16:05:25 I already pasted the link on IRC 16:05:30 q? 16:05:36 ack tobie 16:05:56 Here is the link to Tim's presentation again: https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf 16:06:01 tobie: mounir explained the difference well, one issue re singleton that Tim advocates 16:06:05 ... does not work very well 16:06:30 ... other issues can be decided, mostly matter of taste 16:06:44 ... not really disagreement on key technical questions 16:06:57 mounir: argreed 16:06:59 q? 16:07:17 ack rwaldron 16:08:01 rwaldron: I see these as the same, the proposals are doing the same things 16:08:10 -Claes 16:08:33 Tim's slide deck: https://www.w3.org/2008/geolocation/wiki/images/6/69/TPAC-sensors.pdf 16:08:41 ... our spec works better with a map of active sensors 16:09:03 q? 16:09:14 q+ 16:09:28 ack fjh_ 16:09:35 -anssik 16:09:57 +??P3 16:10:05 zakim, ??P3 is me 16:10:05 +anssik; got it 16:10:12 Topic: Generic Sensor API - Summary, Discussion and Next Steps 16:10:16 fjh: what is next step, create a draft on the list? 16:10:33 general response is to continue on list 16:10:41 q? 16:10:41 Potential next steps 16:10:52 Document known issues with existing APIs (currently spread across issue trackers) 16:11:02 Draft use cases and requirements (consider known issues) 16:11:20 Evaluate the proposals against the requirements 16:11:42 Flesh out the generic sensor API spec 16:11:47 Update the existing concrete sensor API specs to match 16:12:00 Call for volunteers? 16:12:40 q? 16:13:27 mounir: we could do this WebMob IG way 16:13:31 The item noted as a difference between "Sensor API Unification Sketch" (SAUS) and Tim's proposal is actually not a difference at all. Both versions initialize as null and would result in receiving the initial value payload at the same time. The real difference is that Tim's proposal doesn't allow user code to initialize a sensor object and do something with the reference (such as putting it into some sensor registry Map), whereas SAUS gives you the instance 16:13:31 immediately, which allows the reference to be used in interesting ways before the initial payload is delivered. 16:13:50 ... we could have a GH repo, and work these 16:14:25 ... working with script-coord@ 16:15:07 q+ happy to help set the repo up, etc. 16:15:13 q+ 16:15:35 https://github.com/rwaldron/sensors 16:17:31 I can coordinate with Rick + dom for that. 16:17:43 proposed RESOLUTION: move https://github.com/rwaldron/sensors under "w3c" org and work from there, Anssi to check with W3C Team contact Dom 16:18:39 create new git work area to develop the note 16:19:02 proposed RESOLUTION: create a GH repo where we can continue to work, Anssi to check with W3C Team contact Dom 16:19:33 RESOLUTION: create a GH repo where we can continue the work, Anssi to check with W3C Team contact Dom 16:20:37 Topic: Adjourn 16:20:43 rrsagent, generate minutes 16:20:43 I have made the request to generate http://www.w3.org/2014/11/13-dap-minutes.html fjh_ 16:21:30 -PaulBoyes 16:22:16 -ted 16:22:23 -rwaldron 16:22:24