W3C

Device and Sensors Working Group Teleconference

14 Apr 2016

Agenda

See also: IRC log

Attendees

Present
Frederick_Hirsch, Dominique_Hazael-Massieux, Tobie_Langel, Anssi_Kostiainen
Regrets
Chair
Frederick_Hirsch
Scribe
dom, fjh

Contents


<dom> ScribeNick: dom

Welcome, scribe selection, agenda review, announcements

fjh: bunch of news

<fjh> Battery Status API published as a W3C Proposed Recommendation, http://www.w3.org/TR/2016/PR-battery-status-20160329/

<fjh> Sensor WDs published, thanks everyone:

<fjh> Generic Sensor API : https://www.w3.org/TR/generic-sensor/

<fjh> Ambient Light Sensor: https://www.w3.org/TR/ambient-light/

TPAC

<fjh> TPAC 2016, https://www.w3.org/blog/2015/09/tpac-2016-dates-and-location-announced/

<scribe> ScribeNick: fjh

dom: media capture TF would like to use DAP meeting day at TPAC for discussions
... might be useful to have day of meetings around sensors, possibly joint meeting with other groups
... geolocation, and others
... need to give answer by tomorrow

<anssik> Second Screen WG I'm chairing will meet Thu-Fri most likely

<dom> ScribeNick: dom

fjh: we probably should say yes, that we will have a meeting
... I wouldn't need to chair the Media Capture TF
... and the sensors part of the meeting might be chaired by Tobie or Dom

Tobie: we had an unofficial 1/2 day of meeting at last TPAC and it was useful
... I think it will be even more useful this year
... I'm sure that between Dom, Anssi and myself to organize this if needed
... it's probably best if the editor doesn't chair
... but I don't think how this could go wrong
... it'd be ideal if Frederick can be there, but we should plan for it nonetheless

<scribe> ScribeNick: fjh

fjh: lets plan for Mon/Tue

<anssik> I can also volunteer to chair if that does not clash with the Second Screen WG

fjh: not sure one day is enough for sensors

<anssik> (then again, I'm one of the editors)

fjh: my concern is that we need enough time for sensors, could use two days for sensors and other DAP work
... so one day might not be enough for DAP
... need to check if Media Capture is ok with 1/2 day

dom: to clarify, we’ll ask for Mon/Tue for DAP, will do this
... next need to decide how much time to give Media Capture

fjh: need also Wed session for evangelizing and getting support

tobie: can also visit other groups on their time

dom: anssi and I might be involved in Media Capture TF

<anssik> does Geolocation WG meet at TPAC?

<scribe> ACTION: dom to arrange DAP registration for TPAC Mon and Tue [recorded in http://www.w3.org/2016/04/14-dap-minutes.html#action01]

<trackbot> Created ACTION-754 - Arrange dap registration for tpac mon and tue [on Dominique Hazaël-Massieux - due 2016-04-21].

<dom> anssik, I think they were leaning towards not

<anssik> that is another group that should talk with DAS (new name!)

<dom> ACTION: Dom to register Device & Sensors WG to TPAC [recorded in http://www.w3.org/2016/04/14-dap-minutes.html#action02]

<trackbot> Created ACTION-755 - Register device & sensors wg to tpac [on Dominique Hazaël-Massieux - due 2016-04-21].

Minutes approval

Approve minutes from 17 March 2016

proposed RESOLUTION: Minutes from 17 March 2016 are approved, https://www.w3.org/2016/03/17-dap-minutes.html

<dom> ScribeNick: dom

RESOLUTION: Minutes from 17 March 2016 are approved, https://www.w3.org/2016/03/17-dap-minutes.html

Battery Status PR published

<fjh> Battery Status API published as a W3C Proposed Recommendation, http://www.w3.org/TR/2016/PR-battery-status-20160329/

fjh: an issue was raised on our battery API that is at PR

<scribe> ScribeNick: fjh

fjh: do we need to change due to the issue of browsing context, vs document vs window
... aren’t there benefits for privacy etc for browsing context, e.g. per tab/origin etc
... we need anssik on a call to discuss

dom: ditto

If you work for a W3C Member, please make sure your Advisory Committee Representative voices their support for the publication of the document (says Dom)

dom: no need to say anything on AC at this point, lower level for them, also need to determine if we have an issue or not

fjh: agreed, let’s try to have a call with anssik on the call to discuss

<dom> ScribeNick: dom

Media Capture and Streams CfC

<fjh> Call for Consensus (CfC) to transition “Media Capture and Streams” to Candidate Recommendation - deadline 17 April 2016

<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Apr/0008.html

Charter Approved

fjh: thank you Dom for sending the diff to the charter

<fjh> "Device and Sensors Working Group" charter approved, with some changes. One substantive change - new work requires formal incubation phase.

<fjh> For detail on charter see Dom's message: https://lists.w3.org/Archives/Public/public-device-apis/2016Mar/0112.html

<fjh> Charter: https://www.w3.org/2016/03/device-sensors-wg-charter.html

<fjh> Members need to rejoin: "Since the charter includes new deliverables, all the Working Group formal participants will have to re-join the group; there is 45 days grace period for people to rejoin the group during which they can continue their participation to calls and discussions." (Dom). Status?

<fjh> Thanks to Anssi for updating home page.

https://www.w3.org/2004/01/pp-impl/43696/join

<scribe> ScribeNick: fjh

fjh: I thought I was in the group already

dom: no, you need to rejoin

tobie: what about me?

dom: you are all set, Intel is already a member
... will send reminder for companies
... we have another month
... incubation item - new sensor work will require this - pressure, barometer
... can discuss details later
... incubation is only for new deliverables
... including new sensors

fjh: could think of higher level sensor

tobie: happy to publish CG draft

fjh: do we need to set up Community Group

dom: can write draft and bring to web incubator group

Charter Milestone review

Note Q1 and Q2 2016 deliverables

https://www.w3.org/2016/03/device-sensors-wg-charter.html#deliverables

HTML Media Capture implementation status review. CR draft and approved test cases in place.

<dom> fjh: we're in Q2 2016, so we already have a bit of a slip on our charter schedule

<dom> ScribeNick: dom

dom: not meeting milestones can have impact on charter extensions

fjh: we need to keep track on where we are

tobie: what's needed to go to CR?

fjh: go through a LC-like review and some implementations line-up

tobie: we have ambient light that should go to "intent to ship" soon
... not sure what going to CR means for "generic sensor" in terms of implementations
... having ambient light spec'd and implemented makes me comfortable for "push" sensors
... would like to have the same for a "poll" sensor to be comfortable to that part of generic
... I'm not entirely confident on that one; work on accelerometer and device orientation would help
... I should have more details on my work plan soon

fjh: getting a first draft of device orientation would help gaining confidence on that part of generic sensor

tobie: getting a first draft should be fairly fast

fjh: we'll have to figure out if our CR schedule is pre or post TPAC

tobie: writing concrete specs on generic sensor should be fairly simple (once we have had the conversation with the TAG next week)
... the next question is implementability of periodic sensor
... I don't have implementors feedback on that yet, and it might have big implications on generic sensor

<scribe> ScribeNick: fjh

tobie: having more WD of concrete sensors will get interest

fjh: want to use TPAC to get interest and involvement

dom: use TPAC for wide review, effectively replaces LC

<dom> ScribeNick: dom

fjh: so back to scheduling, we need to focus on the sensor stuff
... the media capture work happens in the task force

<scribe> ScribeNick: fjh

fjh: what about Network Information API?

dom: not clear about additional implementations beyond initial ones, not clear whether to progress

fjh: we need to talk with stakeholders

<dom> ScribeNick: dom

Battery issue

<anssik> there's an issue https://github.com/w3c/battery/issues/2, and a proposed fix discussed in https://github.com/w3c/battery/pull/3

fjh: an issue was raised on where the promise is attached

anssik: I think we have a good proposal from Domenic; there is a slight confusion still between Boris and Domenic

<anssik> Realm

anssik: there is a reference to Realms which is not part of HTML5 Rec

<fjh> suggestion from dominic

<fjh> Suggested:

<fjh> Instead of each Document having a battery promise, make it each Navigator object. They are equivalent, but it will be easier to write the following spec text.

<fjh> Make the following updates to the getBattery() method definition:

<fjh> Please number the steps, instead of using bullets.

anssik: we would have an issue with regard to the normative dependency policies

<fjh> Replace all references to "battery promise" with "this Navigator object's battery promise".

<fjh> Replace step 2 with "Otherwise, set this Navigator object's battery promise to a newly created Promise, created in the Realm of this Navigator object."

<fjh> Replace step 4 with "create a new BatteryManager object in the Realm of this Navigator object, and let battery be that object."

<scribe> ScribeNick: fjh

fjh: alreafdy have existing implementations against current spec

anssik: yes

<anssik> https://html.spec.whatwg.org/#realm-execution-context

<dom> ScribeNick: dom

anssik: without this change, the spec is ambiguous on this aspect
... there can be interop issues in nested browsing contexts (e.g. iframes)

tobie: can you change the spec to match without referring to realms?

fjh: I'm still not sure to understand if this is necessary to spec out

<anssik> https://github.com/w3c/battery/issues/2#issue-147603649

anssik: domenic's test case illustrate the problem
... in most use cases, it's probably not an issue, but it's an issue nevertheless

fjh: I'm trying to understand why would it matter to an app

anssik: in "normal" use, no issues

<scribe> ScribeNick: fjh

dom: can we refer to ECMAScript concept vs living standard
... is change from browing context to document enough, or is more needed?

anssik: makes it better, dominc’s changes makes it even more precise

dom: in PR, would need to go back to WD
... want best spec possible

fjh: agree, want to make sure we know what to leave as implementation details, v2

anssik: so make current version be for document not browsing context, make realm changes for v2, especially since still under disussion

<scribe> ScribeNick: fjh

dom: also need to decide if full formal cycle for this change

anssiK; change aligns spec with implementations, does not break implementations

dom: if we agree on pull request 3, it is more a clarification than substantive change, will check on process

<anssik> domenic's change proposal baking in Realm https://github.com/w3c/battery/pull/3#issuecomment-209625181

Sensors

tobie: working on test suites now

Generic Sensor and Ambient Light Sensor TAG reviews (Tobie)

https://lists.w3.org/Archives/Public/public-device-apis/2016Apr/0006.html

“The Generic Sensor API is due to be discussed on the TAG's 2016-04-20

call."

<anssik> https://github.com/w3ctag/spec-reviews/issues/115

<anssik> https://github.com/w3ctag/spec-reviews/issues/110

tobie: got some feedback to clarify how sensor work, also need to work through permissioning

fjh: can defer privacy discussion, let it continue on list, Lucaz not on call

tobie: not surprised by new features exposing new fingerprinting and other issues
... suggest strategies to encourage higher level APIs, incentives e.g . different permission models

Other Business

fjh: so we have plan for going forward with Battery - Anssi to make change of browsing context to document for PR, Dom to determine process for moving this change forward
... dom to reserve Mon/Tue at TPAC for DAP, we need to determine how much for Media Capture Task Force (frederick)
... Tobie and Anssi to look into reserving slot on TPAC Wed for sensors to get more involvement
... Dom to remind on AC to join DAS

Adjourn

Summary of Action Items

[NEW] ACTION: dom to arrange DAP registration for TPAC Mon and Tue [recorded in http://www.w3.org/2016/04/14-dap-minutes.html#action01]
[NEW] ACTION: Dom to register Device & Sensors WG to TPAC [recorded in http://www.w3.org/2016/04/14-dap-minutes.html#action02]
 

Summary of Resolutions

  1. Minutes from 17 March 2016 are approved, https://www.w3.org/2016/03/17-dap-minutes.html
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2015/11/17 08:39:34 $