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/
<fjh> dom: media capture TF would like to use DAP meeting day at TPAC for discussions
<fjh> dom: might be useful to have day of meetings around sensors, possibly joint meeting with other groups
<fjh> dom: geolocation, and others
<fjh> dom: need to give answer by tomorrow
<anssik> Second Screen WG I'm chairing will meet Thu-Fri most likely
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
<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> fjh: not sure one day is enough for sensors
<anssik> (then again, I'm one of the editors)
<fjh> fjh: my concern is that we need enough time for sensors, could use two days for sensors and other DAP work
<fjh> fjh: so one day might not be enough for DAP
<fjh> fjh: need to check if Media Capture is ok with 1/2 day
<fjh> dom: to clarify, we’ll ask for Mon/Tue for DAP, will do this
<fjh> dom: next need to decide how much time to give Media Capture
<fjh> fjh: need also Wed session for evangelizing and getting support
<fjh> tobie: can also visit other groups on their time
<fjh> dom: anssi and I might be involved in Media Capture TF
<anssik> does Geolocation WG meet at TPAC?
<fjh> 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].
anssik, I think they were leaning towards not
<anssik> that is another group that should talk with DAS (new name!)
<scribe> 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].
<fjh> Approve minutes from 17 March 2016
<fjh> proposed RESOLUTION: Minutes from 17 March 2016 are approved, https://www.w3.org/2016/03/17-dap-minutes.html
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
<fjh> fjh: do we need to change due to the issue of browsing context, vs document vs window
<fjh> fjh: aren’t there benefits for privacy etc for browsing context, e.g. per tab/origin etc
<fjh> fjh: we need anssik on a call to discuss
<fjh> dom: ditto
<fjh> 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)
<fjh> 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> fjh: agreed, let’s try to have a call with anssik on the call to discuss
<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
<fjh> fjh: I thought I was in the group already
<fjh> dom: no, you need to rejoin
<fjh> tobie: what about me?
<fjh> dom: you are all set, Intel is already a member
<fjh> dom: will send reminder for companies
<fjh> dom: we have another month
<fjh> dom: incubation item - new sensor work will require this - pressure, barometer
<fjh> dom: can discuss details later
<fjh> dom: incubation is only for new deliverables
<fjh> dom: including new sensors
<fjh> fjh: could think of higher level sensor
<fjh> tobie: happy to publish CG draft
<fjh> fjh: do we need to set up Community Group
<fjh> dom: can write draft and bring to web incubator group
<fjh> Note Q1 and Q2 2016 deliverables
<fjh> https://www.w3.org/2016/03/device-sensors-wg-charter.html#deliverables
<fjh> HTML Media Capture implementation status review. CR draft and approved test cases in place.
fjh: we're in Q2 2016, so we already have a bit of a slip on our charter schedule
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
<fjh> tobie: having more WD of concrete sensors will get interest
<fjh> fjh: want to use TPAC to get interest and involvement
<fjh> dom: use TPAC for wide review, effectively replaces LC
fjh: so back to scheduling, we
need to focus on the sensor stuff
... the media capture work happens in the task force
<fjh> fjh: what about Network Information API?
<fjh> dom: not clear about additional implementations beyond initial ones, not clear whether to progress
<fjh> fjh: we need to talk with stakeholders
<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."
<fjh> fjh: alreafdy have existing implementations against current spec
<fjh> anssik: yes
<anssik> https://html.spec.whatwg.org/#realm-execution-context
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
<fjh> dom: can we refer to ECMAScript concept vs living standard
<fjh> dom: is change from browing context to document enough, or is more needed?
<fjh> anssik: makes it better, dominc’s changes makes it even more precise
<fjh> dom: in PR, would need to go back to WD
<fjh> dom: want best spec possible
<fjh> fjh: agree, want to make sure we know what to leave as implementation details, v2
<fjh> anssik: so make current version be for document not browsing context, make realm changes for v2, especially since still under disussion
<fjh> 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
Topics: 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
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
... Anssi to update editors draft for Dominic change, inform
him, should be good way forward to ongoing changes, can
consider when to have v2
... 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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/might/will/ Succeeded: s/incubator/web incubator/ Succeeded: s/internest/interest/ Succeeded: s/change/change proposal/ Found ScribeNick: dom Found ScribeNick: fjh Inferring Scribes: dom, fjh Scribes: dom, fjh ScribeNicks: dom, fjh Present: Frederick_Hirsch Tobie_Langel Anssi_Kostiainen Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Apr/0009.html Found Date: 14 Apr 2016 Guessing minutes URL: http://www.w3.org/2016/04/14-dap-minutes.html People with action items: dom[End of scribe.perl diagnostic output]