See also: IRC log
<dom> ScribeNick: dom
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/
<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].
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
<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
<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
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
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
<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
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
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