- 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