See also: IRC log
<fjh> trackbot, start telecon
<trackbot> Meeting: Device and Sensors Working Group Teleconference
<trackbot> Date: 21 September 2017
<dom> ScribeNick: anssik
<fjh> GitHub digests
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Sep/0016.html
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Sep/0019.html
<fjh> review request, Vehicle Information Service Specification, Vehicle Information API Specification
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Sep/0018.html
fjh: there was a review request for Vehicle Information Service Specification, Vehicle Information API Specification
dom: Web Auto WG is bringing these specs to CR soon
... two work items, i) API which is a wrapped for the ii) protocol
... would be interesting for someone with Generic Sensor expertise to review the Web Auto WG specs, but not spend excess time on it
<fjh> anssik: early thought from Tobie was that they could use Generic Sensor approach
<fjh> dom: TAG suggested alternate approach to use protocol; API wrapper can be an issue
dom: TAG review feedback caused Web Auto WG to reorientate their work, started working on a protocol-level spec
anssik: any implementations available for these specs?
dom: only experimental, but no clear on details
alexander: we'd like to review
<fjh> ACTION: alexander to review Automotive specifications with regards to Generic Sensor API [recorded in http://www.w3.org/2017/09/21-dap-minutes.html#action01]
<trackbot> Created ACTION-809 - Review automotive specifications with regards to generic sensor api [on Alexander Shalamov - due 2017-09-28].
anssik: they may have some requirements that might motivate new features in Generic Sensor v.next
<fjh> dom: we should be able to learn from this
<fjh> Approve minutes from 7 Sept 2017
<fjh> https://www.w3.org/2017/09/07-dap-minutes.html
<fjh> proposed RESOLUTION: Minutes from 7 Sept 2017 are approved
RESOLUTION: Minutes from 7 Sept 2017 are approved
<fjh> Call for Consensus: discontinue joint ownership of Media Capture Task Force, leaving to WebRTC Working Group; respond by 20 Sept 2017
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Sep/0017.html
Call for Consensus: discontinue joint ownership of Media Capture Task Force, leaving to WebRTC Working Group; respond by 20 Sept 2017
fjh: no concerns raised to separate the two
dom: that's my interpretation too
<fjh> ACTION: fjh to send email confirming CfC conclusion [recorded in http://www.w3.org/2017/09/21-dap-minutes.html#action02]
<trackbot> Created ACTION-810 - Send email confirming cfc conclusion [on Frederick Hirsch - due 2017-09-28].
<fjh> 1 hour Wed Session? Vincent to chair?
<fjh> https://www.w3.org/wiki/TPAC/2017/SessionIdeas#Device
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Sep/0014.html
anssik: breakout will be pretty ad-hoc
<fjh> 2 proposals:
<fjh> A - with the current spec, we could publish a CR soonish, and if the feedback from Web developers motivate change, we might need to revise it
<fjh> B - we wait until we get that feedback, and only then publish CR
fjh: two CR publication plans
<fjh> no decision yet on A or B
<fjh> wide review for Generic Sensor API, Ambient Light Sensor, Accelerometer, Gyroscope, Magnetometer, Orientation Sensor together
<fjh> ACTION-805?
<trackbot> ACTION-805 -- Dominique Hazaël-Massieux to Work with frederick on getting a wide review question on sensor specs (- proximity), pointing out motion sensors explainer -- due 2017-09-14 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/805
dom: need to do wide review prior to thinking of CR publication
https://github.com/w3c/sensors/blob/master/security-questionnaire.md
security and privacy questionnaire results
alexander: I agree with dom, we should split those to separate repos
... can do that tomorrow
dom: will work with fjh on wide review logistics
<fjh> dom: will work with fjh next week, after split complete
fjh: why not include proximity in the wide review?
dom: too many documents in review, will probably mean less focus on specs that are further down the process
https://www.w3.org/2009/dap/#roadmap
fjh: who'd be the usual suspects to review this work
dom: we discussed this on last call, so we have a list of groups to target
<fjh> ACTION-806?
<trackbot> ACTION-806 -- Anssi Kostiainen to Get in touch with webvr cg on wide review of motion sensor specs -- due 2017-09-14 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/806
anssik: please include explainer in the review, good background
https://intel.github.io/generic-sensor-demos/vr-button/build/bundled/
https://github.com/intel/generic-sensor-demos/tree/master/vr-button/build/bundled
anssik: also WebVR polyfill could benefit from the low-level sensors
<fjh> community group, anssik will send informal request
anssik: one concrete use case would be to enable magnetic input in WebVR using Magnetometer
fjh: we're ready for wide review
... status of the open issues?
... after wide review completed, go to CR, how to deal with open issues
... assess where we are in terms of open issues
... going to wide review equals last call in the old process
<fjh> Plan: wide review before transition to CR, deadline 30 Sept, then CR
<fjh> https://lists.w3.org/Archives/Member/chairs/2017JulSep/0104.html
<fjh> wait until review period ends then progress
<fjh> status? PR #13 in review, after landed and implemented in Chrome, can publish revised CR
fjh: current status?
<fjh> ACTION-808?
<trackbot> ACTION-808 -- Dominique Hazaël-Massieux to Look into the need to get wide review of revised battery -- due 2017-09-14 -- OPEN
<xfq> ScribeNick: fjh
<trackbot> http://www.w3.org/2009/dap/track/actions/808
anssik: mounir looking to see how often cross iframe battery cases are used
... others are ok with it
<anssik> That is, in an A->B->A embedding scenario, both the top-level and the innermost frame would be able to use the battery API. With feature policy, the inner frame wouldn't be allowed to use it, unless the top-level doc granted it to the middle frame, which then further granted it to the inner one.
anssik: have integrated spec with feature policy
... will wait a week or two for feedback, then merge
... then go to CR and await additional browser implementations
<dom> Feature Policy status in Chrome platform status - indicates public support from Edge
fjh: go to CR end Oct
<dom> Microsoft stance on the spec
<xfq> ScribeNick: anssik
https://github.com/w3c/dap-charter/
http://w3c.github.io/dap-charter/DeviceAPICharter.html
<dom> https://github.com/w3c/dap-charter/issues
<fjh> 3, 30, 29 issues of scope are substantive
dom: substantial issue: 1) scope, whether to integrate WebNFC, WebUSB, environmental sensors
<fjh> dom suggests answer should be no
<fjh> anssi: NFC is higher level api than last time
dom: I asked Vincent about his breakout session at TPAC, and whether that would have impact on the rechartering i.e. whether to do more work in DAS or not
<fjh> ACTION: fjh to review charter [recorded in http://www.w3.org/2017/09/21-dap-minutes.html#action03]
<trackbot> Created ACTION-811 - Review charter [on Frederick Hirsch - due 2017-09-28].
dom: apart from that the charter is ready for W3M review
... heads up, if there are issues that need further discussion, good time to raise now
fjh: I'm looking track whether W3C wants megagroups or smaller focused
dom: there's no policy on that
fjh: how does the chair selection work
dom: in general, charters are reviewed with expected chair
... plan, work next week on admin tasks, early October bring to W3M
<wanming> sorry, the line is very noise, I can't hear clearly.
<fjh> we discussed moving the call an hour earlier, any concern?
anssik: +1
<wanming> no, it's great
<fjh> ScribeNick: fjh
RESOLUTION: move DAS call 1 hour earlier, e.g. 9am ET, on same schedule
fjh: Dom and Fuqiao to update DAS calendar and webex accordingly