- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 15 Jun 2017 16:55:22 +0200
- To: W3C Device APIs WG <public-device-apis@w3.org>
Hi, The draft minutes of our teleconference are available at: https://www.w3.org/2017/06/15-dap-minutes.html and copied as text below. Dom - DRAFT - Device and Sensors Working Group Teleconference 15 Jun 2017 [2]Agenda [2] https://lists.w3.org/Archives/Public/public-device-apis/2017Jun/0002.html See also: [3]IRC log [3] http://www.w3.org/2017/06/15-dap-irc Attendees Present Alexander_Shalamov, Wanming_Lin, Dom, Anssi, Kenneth, MIkhail Regrets Frederick Chair Dom Scribe anssik, dom Contents * [4]Topics 1. [5]Minutes approval 2. [6]HTML Media Capture 3. [7]Sensors API 4. [8]Wake lock 5. [9]Battery Status API 6. [10]Rechartering 7. [11]Other Business * [12]Summary of Action Items * [13]Summary of Resolutions __________________________________________________________ <kenneth_> +Present KennethRohdeChristiansen Minutes approval <dom> ScribeNick: anssik <dom> Proposed RESOLUTION: Minutes from 18 May 2017 are approved [14]https://lists.w3.org/Archives/Public/public-device-apis/201 7May/att-0024/minutes-2017-05-18.html [14] https://lists.w3.org/Archives/Public/public-device-apis/2017May/att-0024/minutes-2017-05-18.html proposed RESOLUTION: Minutes from 18 May 2017 are approved RESOLUTION: Minutes from 18 May 2017 are approved HTML Media Capture dom: checking if we can go to PR next month ... is that correct? [15]http://w3c.github.io/test-results/html-media-capture/201704 28.html [15] http://w3c.github.io/test-results/html-media-capture/20170428.html <dom> [16]HTML Media Capture Test Results [16] http://w3c.github.io/test-results/html-media-capture/20170428.html dom: the 1 failing test case could be not applicable as well ... have to wait for couple of weeks before entering PR Sensors API dom: what is our vision to bring the work to CR? ... what needs to be update re wide reviews <inserted> ScribeNick: dom anssik: we want to get closure on open pull requests ... then we should triage open issues ... I would like to have level 1 issues marking what we want to get in our CR ... the rest would be for later versions ... goal is to go to CR this year ... [this is for generic sensor, but we would also want to go to CR with some of the most-baked concrete sensors] <anssik> dom: what's your feeling on the actual timeline? anssik: timeline will depend on editorship situation ... assuming dedicated full time editorship, this would need addressing level 1 issues (~30) kenneth: there is also the F2F to take into account in the picture ... it helps with getting a broad overview of the status alex: closing issues can be fast, but some of them have dependencies to other groups / specs anssik: plan is to have outside TPAC F2F; but we can still have an unofficial session at TPAC kenneth: but for coordination, TPAC remains nice even if DAS is not meeting formally <inserted> ScribeNick: dom anssik: chrome origin trial starting in the near future ... we would want to include that feedback in the spec prior to CR ... CR this year is optimistic - but that should be our target ... which means we should have a CR-worthy spec by the time of TPAC mikhail: it would be nice to align spec / implementation prior to origin trial <inserted> ScribeNick: anssik dom: the chair is looking at the editorship issue ... after that we can get clarify on the timeline <dom> ACTION: Alexander to take a stab a level-1 issue classification [recorded in [17]http://www.w3.org/2017/06/15-dap-minutes.html#action01] [17] http://www.w3.org/2017/06/15-dap-minutes.html#action01 <trackbot> Created ACTION-800 - Take a stab a level-1 issue classification [on Alexander Shalamov - due 2017-06-22]. Wake lock [the editor not on the call] dom: new activity, suggestions from Microsoft ... hoping to be able to take this to CR Battery Status API dom: two things: new activity on issue #10 ... and secondly, revised CR plan [18]https://github.com/w3c/battery/issues/10 [18] https://github.com/w3c/battery/issues/10 <dom> anssi: mounir noticed the security change in issue 10 [19]https://github.com/w3c/battery/issues/5#issuecomment-257554 180 [19] https://github.com/w3c/battery/issues/5#issuecomment-257554180 <dom> sounds like another case where we might want to rely on [20]https://wicg.github.io/feature-policy/ too [20] https://wicg.github.io/feature-policy/ dom: perhaps iframed content that shares the origin with the top-level should not be restricted <dom> " The Battery API can be used by third party content for valid reasons." [21]https://github.com/w3c/battery/issues/10#issuecomment-30810 7841 [21] https://github.com/w3c/battery/issues/10#issuecomment-308107841 dom: do we want to reopen issue #10? ... or do research first? anssik: maybe reopening is the right thing to do ... just reopened [22]https://github.com/w3c/battery/issues/10 [22] https://github.com/w3c/battery/issues/10 dom: should be feedback from people who chimed in on issue #5 <dom> dom: also, worth noting that mounir is pointing at real-world usage of the battery api for a/b testing - probably worth highlighting to get interest from more implementors Rechartering dom: current charter expiring by the end of this year, assume we want to continue beyond this year to finish the current work and possibly adopt new work possible candidates for inclusion in this group: <dom> [23]https://www.w3.org/TR/orientation-event/ https://www.w3.org/TR/orientation-event/ * taking over device orientation v1? * geo v2? * webbluetooth? * webusb? * webnfc? dom: Geolocation WG closed, had Geolocation API and Device Orientation API in scope ... Device Orientation API was not finished, suggestion for DAS to take the spec to REC ... also Geolocation API "v2" a possibility, e.g. background operation ... WebBT, WebNFC, WebUSB also would be natural extensions to the DAS group <inserted> ScribeNick: dom anssi: DAS WG is probably the best fit for all of these work items in terms of scope ... Device Orientation would benefit from the sensor expertise of this group ... geo could remodeled after generic sensor ... the 3 incubation specs (bluetooth, nfc, usb) would benefit from more common interactions ... incl in F2F and/or calls ... they share a lot in common (e.g. permission model, API shape) - we could learn from each other ... WebBluetooth is enabled by default in Chrome ... WebUSB is in intent to ship [24]https://www.chromestatus.com/features/5651917954875392 [24] https://www.chromestatus.com/features/5651917954875392 [25]WebNFC Chrome status [25] https://www.chromestatus.com/features/6261030015467520 scribe: WebNFC will go to origin trial in the near future ... would be good to transition to WG ... adding these to this group would also help diversify participation which would be good <anssik> dom: that's the first level of support for extending the group <anssik> ... if we do this, we'd expect the CG participants from the related CGs to join this WG <anssik> ... will take this discussion to the list Other Business Summary of Action Items [NEW] ACTION: Alexander to take a stab a level-1 issue classification [recorded in [26]http://www.w3.org/2017/06/15-dap-minutes.html#action01] [26] http://www.w3.org/2017/06/15-dap-minutes.html#action01 Summary of Resolutions 1. [27]Minutes from 18 May 2017 are approved
Received on Thursday, 15 June 2017 14:55:31 UTC