See also: IRC log
<trackbot> Date: 18 September 2014
<mats> fjh: sensors are a topic of interest (thus, 6 and 7) but not sure I have enough to add today to rearrange the agenda
<mats> rather 7 and 8
<fjh> CR drafts of HTML Media Capture and Vibration API published http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0050.html
<scribe> scribenick: dom
fjh: TPAC registration is open
<fjh> Reminder, TPAC registration is open (however, DAP has no plans to meet) http://www.w3.org/2014/11/TPAC/
fjh: DAP is not meeting, but deadlines are up coming
giri: we'll have a Geo F2F at TPAC; we have two days scheduled but may only need one day
... the generic sensor api is relevant to Geo as well
... I wonder if it would make sense to use the 2nd day of the Geo F2F for this
fjh: I plan to be on TPAC; not sure where I'll be exactly on that day
... it makes sense to discuss this
... Anssi will be there I assume
Giri: so I'll assume we can add that to the Geo agenda and we'll have people from DAP that can attend to share their views
fjh: makes sense; I don't think we'll be in a position to make decisions there though
Giri: right, we'll make this an intro discussion
... I'll get in touch with you offline to figure this out
fjh: I'd come with my DAP chair hat
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0048.html
fjh: there is interest in health-sensor oriented APIs
... I believe that the right thing to do is to add a slot in the DAP charter
... so that we can do the work
... but I think a CG would be better positioned to do the use case / req work
... I think a dedicated CG is more appropriate since the topic isn't mobile specific
... and CGs can progress work more easily
... I don't think anybody disagreed this is interesting work
... assuming IPR isn't an issue
Giri: one of the hard things is the lack of support for health-centered targeted bluetooth protocols in native platforms
... I don't think we're ready to say it belongs in DAP; it depends on where bluetooth work goes in W3C
... a CG seems a better path forward
fjh: you're right that this touches different levels, and a WG might not be the best place
... a workshop might be appropriate
<fjh> suggest path is workshop, community group then standardization as appropriate
<fjh> dom: workshop good idea, if anyone can put time into this contact me
Claes: This could be a sub-task in the WoT group
... has that been considered?
fjh: good idea too
... It really depends on what we're exactly talking about
... which is hard to determine without going into the details
... I was thinking a CG or a workshop could help us go there
... it seems too vague at this point
... there are many different aspects in what e.g. Apple is doing in this space
... (secure storage, sensor access, etc)
... hence why a workshop might help hash things out
... Was this discussed at the WoT workshop?
... I suspect this hasn't been figured out yet
Claes: I can agree that a workshop might be a good starting point
fjh: part of the question is whether the communities of health apps overlap with the community that attended the IoT workshop
mats: generally, there are lots of small and big communities, hard to know which to follow
... I'll go look for the things we've mentioned
... in my case, we're just barging ahead inventing things that haven't seen enough light of day yet
... I'm using input this forum to pitch back to my guys
<fjh> "w3c Workshop of the Web of Things" http://www.w3.org/2014/02/wot/
mats: moving a bit more slowly is not necessary a bad idea
fjh: I think we need the focus first and foremost
... we don't want to do rework as much as possible
<fjh> fjh: dom what is process for proceeding with workshop
<fjh> dom: could have breakout at TPAC
<fjh> fjh: very good idea
fjh: break out sounds like a good idea; willing to help, but I'm not a subject matter expert
... anyone interested in leading something there?
dom: maybe get it started and then find someone else to drive it? :)
<fjh> ACTION: fjh to set up TPAC breakout on Web API for Health Care Sensors [recorded in http://www.w3.org/2014/09/18-dap-minutes.html#action01]
<trackbot> Created ACTION-718 - Set up tpac breakout on web api for health care sensors [on Frederick Hirsch - due 2014-09-25].
fjh: lots of design discussion on the list
... what does the group suggest we should do here?
<fjh> dom: we have one firefox implementation - that triggered redesign
<fjh> dom: took action to see if Rick could be involved in DAP
<fjh> ACTION-716?
<trackbot> ACTION-716 -- Dominique Hazaël-Massieux to Add rwalron as invited expert to dap group -- due 2014-09-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/716
<fjh> dom: Rick is now member of group and is very interested in helping in moving this forward
<fjh> dom: need to make sure he can make contributions
fjh: I'll follow up with him
<fjh> fjh: excellent
<fjh> ACTION: fjh to follow up with rwaldron [recorded in http://www.w3.org/2014/09/18-dap-minutes.html#action02]
<trackbot> Created ACTION-719 - Follow up with rwaldron [on Frederick Hirsch - due 2014-09-25].
<fjh> close ACTION-716
<trackbot> Closed ACTION-716.
<fjh> Approve minutes from 4 September 2014
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/att-0020/minutes-2014-09-04.html
<fjh> proposed RESOLUTION: Minutes from 4 September 2014 are approved
RESOLUTION: Minutes from 4 September 2014 are approved
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0038.html (Zhiqiang)
fjh: Zhiqiang updated the implementation report and made a snapshot
Dom: maybe run a CfC on the test suite and the implementation report?
<fjh> ACTION: fjh to send CfC asking if vibration test and implementation report is correct and complete [recorded in http://www.w3.org/2014/09/18-dap-minutes.html#action03]
<trackbot> Created ACTION-720 - Send cfc asking if vibration test and implementation report is correct and complete [on Frederick Hirsch - due 2014-09-25].
fjh: looking at the process for entrance to PR
<fjh> to go to PR we have the following
<fjh> must show adequate implementation experience except where an exception is approved by the Director,
<fjh> must show that the document has received wide review,
<fjh> must show that all issues raised during the Candidate Recommendation review period other than by Advisory Committee representatives acting in their formal AC representative role have been formally addressed,
<fjh> must identify any substantive issues raised since the close of the Candidate Recommendation review period by parties other than Advisory Committee representatives acting in their formal AC representative role,
<fjh> may have removed features identified in the Candidate Recommendation document as "at risk" without republishing the specification as a Candidate Recommendation.
fjh: seems like we're in good shape
fjh: how do we progress this one? do we have the right report ready yet?
http://w3c.github.io/test-results/html-media-capture/all.html
dom: we have a report that shows 2 failures
... need to figure out whether they're being fixed by implementors
<fjh> do Zhiquiang or Anssi have any suggestion
dom: we should ask implementors what their plans are for this
<fjh> dom: have any bug reports that indicate whether this will get fixed
(linked from https://www.w3.org/2009/dap/wiki/ImplementationStatus )
<fjh> Cordova gap analysis http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0052.html
fjh: Thank you Lisa for your gap analysis on Cordova battery API
... looks comprehensive
Lisa: will definitely be more work than for Vibration
... Cordova is pretty far off from the DAP API
... it looks like the battery spec is based on Promises
<fjh> it is supported in ios8
Lisa: not sure that promises are supported in older iOS WebViews
dom: it wasn't indeed
... but I think that they can be polyfilled reasonably simply
Giri: Media Capture didn't go with promises as they could be polyfilled via libraries
Lisa: the older versions of webkit views in iOS don't support Promises, so we'll need a workaround
Giri: I guess it sounds like the work around isn't too hard to establish
<gmandyam> jQuery promise API: http://api.jquery.com/promise/
<fjh> dom: look for promises polyfill
Lisa: I'll go back to the Cordova team with that approach
Dom: note that jQuery promises aren't compatible with Ecmascript one
<fjh> dom: JQuery promises might not be compatibile with the standards
Lisa: I've identified 14 points for alignment
... assume this is OK with everyone
... will submit this as issues
<fjh> anssik: were you able to review the cordova battery alignment document
<gmandyam> My point was that I don't understand why Cordova requires native promise support to implement for battery API. Frameworks like jQuery don't rely on it.
<fjh> fs/anssik:/anssik,/
dom: I've looked at the document and it looked good to me
... seems like more work indeed this time around; let us know if we can help!
<anssik> fjh: no I haven't reviewed it
<fjh> lisa: will go ahead with next steps
fjh: we also have a CfC on the resolution to Tobie's LC comment
<fjh> CfC for LC-2965, http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0054.html
fjh: Tobie agreed this was reasonable
<LisaDeLuca_IBM> Lisa next steps: Opening 14 JIRA issues in Cordova tracking system. Cordova committers will then assign issues to themselves and move forward with implementation. If issues arise with concerns about promises I will get back to the DAP team.
<fjh> Status and questions http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0018.html
fjh: some discussion on the list following Rich's status report
... some support for high and low level
Claes: I don't have a very strong opinion
... doesn't seem to be much implementors interest
... hence why I was mentioning the high level presentation API as an alternative
... is there really use for the low level API, or will the other approaches dominate the solution space
fjh: the question is how to find the right level of layering
... I have concerns with complexity and testability of the low level interactions
... it feels maybe premature
... I'm trying to figure a sensible way forward
... let's continue the discussion on the list; I'll try to drive responses to the questions
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2014Sep/0061.html
<fjh> This CfC ends next week, Friday, 26 Sept 2014.
<fjh> ACTION-712?
<trackbot> ACTION-712 -- Dominique Hazaël-Massieux to Look into chartering extensibility -- due 2014-09-18 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/712
<fjh> ACTION-714?
<trackbot> ACTION-714 -- Zhiqiang Zhang to Update implmentation report to clarify explicitly which tests are for desktop or mobile -- due 2014-09-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/714
<fjh> close ACTION-714
<trackbot> Closed ACTION-714.
<fjh> ACTION-715?
<trackbot> ACTION-715 -- Frederick Hirsch to Send cfc to close lc-2965 with proposal to continue existing battery api with v.next if needed -- due 2014-09-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/715
<fjh> close ACTION-715
<trackbot> Closed ACTION-715.
<fjh> ACTION-717?
<trackbot> ACTION-717 -- Frederick Hirsch to Note on webapps list that this is alreadyin dap charter, so could be done in dap if needed, permissions api -- due 2014-09-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2009/dap/track/actions/717
<fjh> close ACTION-717
<trackbot> Closed ACTION-717.
<fjh> none
<fjh> Next meeting 2 October, http://www.w3.org/2009/dap/minutes.html#upcoming-teleconferences
<fjh> thanks much for scribing Dom