W3C

Device APIs Working Group Teleconference

29 May 2013

Agenda

See also: IRC log

Attendees

Present
Anssi_Kostiainen, Diana_Cheng, Dominique_Hazael-Massieux, Frederick_Hirsch, Giri_Mandyam, Josh_Soref, Laszlo_Gombos, Milan_Patel
Regrets
Bryan_Sullivan
Chair
Frederick_Hirsch
Scribe
Josh_Soref

Contents


<trackbot> Date: 29 May 2013

Welcome, agenda review, scribe selection, announcements

<fjh> http://www.w3.org/2013/05/22-dap-minutes.html

<fjh> I updated the home page roadmap http://www.w3.org/2009/dap/

<fjh> separated roadmap into sections so that rec track stages like CR are not present for informative Notes and exploratory work etc, should be clearer

<fjh> also moved shelved material and Web Intents Note

<fjh> Media Capture and Streams heading to Last Call, deadline 15 June, http://lists.w3.org/Archives/Public/public-media-capture/2013May/0105.html

<fjh> bug link, https://www.w3.org/Bugs/Public/buglist.cgi?product=WebRTC%20Working%20Group&component=Media%20Capture%20and%20Streams&resolution

<Zakim> dom, you wanted to discuss Media Capture and Streams

<fjh> futures call next week, http://lists.w3.org/Archives/Public/public-media-capture/2013May/0111.html

<dom> Date and time (and draft agenda) Futures teleconf

Minutes Approval

<fjh> 22 May minutes, http://lists.w3.org/Archives/Public/public-device-apis/2013May/att-0072/minutes-2013-05-22.html

<scribe> scribe: Josh_Soref

RESOLUTION: Minutes from 22 May are approved

<gmandyam> +q

<fjh> fjh: note no call 26 June

gmandyam: re: MC and Streams
... no one wants this to go to LC
... and then get a bunch of comments from people reading the spec for the first time
... it'd be good if you could send an email to the dap list, trying to spur members to read it and send comments to MediaCap ML

fjh: i'll do that, i was thinking about that
... yesterday, and debating with myself
... thinking people should be on that ML if they care
... but, you're right, it's better to send out the request

Vibration

<fjh> One LC comment so far, resolved: https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-vibration-20130523/doc/

fjh: Paul_Cotton from HTML WG noted we were referencing HTML5.1 content
... anssik fixed it, so we're now referencing html5

<fjh> Question regarding user visibility as to whether in 'silent mode' - http://lists.w3.org/Archives/Public/public-device-apis/2013May/0064.html (Felipe)

Josh_Soref: i was tempted to reply "you should use the Notification API"

fjh: i don't think it's applicable to the vibration spec per se
... the platform could do something

<anssik> "the API is not meant to be used as a generic notification mechanism."

<anssik> http://dev.w3.org/2009/dap/vibration/#introduction

<anssik> +1 for Josh replying politely

Josh_Soref: i'll try to reply today noting the introduction from vibration, and pointing to the notification api

<anssik> thanks Josh

<fjh> +1, seems right approach

<fjh> LC period ends 13 June.

anssik: no spec is too short, people still don't read them
... maybe we should put it in bold
... perhaps Josh_Soref, you could include more context
... e.g., if the app is in the background, this api generally won't work

fjh: i'd simply say there's a notification api that handles various cases like that

Josh_Soref: we could include an informative note at the top of this spec pointing to the Notification API

fjh: good idea

anssik: i could probably do that
... is w3 still working on Web Notification?
... or is it in whatwg?
... the ED seems to be still in w3

fjh: i don't remember
... i think it was whatwg

anssik: it seems like they're syncing
... hober edited the spec 4 days ago

dom: it's still a w3c draft

<fjh> https://dvcs.w3.org/hg/notifications/shortlog

anssik: we can link to the ED

<anssik> https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html

anssik: as there isn't a current TR draft
... there's a bug with the presentation of that spec as it references http: from https: which modern browsers don't allow

<fjh> ACTION: anssik to update introduction of vibration to refer to notification API [recorded in http://www.w3.org/2013/05/29-dap-minutes.html#action01]

<trackbot> Created ACTION-634 - Update introduction of vibration to refer to notification API [on Anssi Kostiainen - due 2013-06-05].

anssik: i patched ReSpec.js for this, but it's using Anolis

Josh_Soref: should i mention in my reply to this guy that we're going to update the document to hint that?

fjh: you could say we're considering it

<fjh> will update tracker accordingly

fjh: i think everyone agrees we'll change this
... i don't think we need a CfC
... the LC is open until June 13

Proximity, Light

<fjh> As decided at last meeting, waiting until end of May for discussion on list.

<fjh> Please review draft and discuss on list.

fjh: i may/may not offer more suggestions about privacy

<anssik> http://lists.w3.org/Archives/Public/public-device-apis/2013May/0008.html

fjh: if you haven't looked in a while, you should take another look

anssik: i summarized the situation w/ merging the interfaces

fjh: and you edited the draft to include the changelog

<fjh> drafts include change log now, http://lists.w3.org/Archives/Public/public-device-apis/2013May/0071.html

anssik: yeah, it's tedious to find changes in mercurial
... most of the time it's easier to review change logs directly
... maybe we should consider doing that for other specs

fjh: we can consider that when we edit other specs

anssik: cvs also provides human readable changelogs

fjh: anything to help people
... i wouldn't expect them to appear in LC/CR drafts

anssik: but yeah, for EDs

fjh: if you want to do that for other EDs, that's fine w/ me
... i assume dom has no concern

dom: no concern indeed

fjh: ok, go for it when you have time

Network Service Discovery

<fjh> prefix issue , http://lists.w3.org/Archives/Public/public-device-apis/2013Apr/0054.html (Jean-Claude)

<fjh> status http://lists.w3.org/Archives/Public/public-device-apis/2013May/0028.html (Rich)

<fjh> Awaiting further activity

Test cases and Interop

<fjh> Request for implementation status, http://lists.w3.org/Archives/Public/public-device-apis/2013May/0069.html

<fjh> wiki http://www.w3.org/2009/dap/wiki/ImplementationStatus

fjh: stuff for interop is blank for all our specs

Josh_Soref: the battery section and media capture are structured differently

anssik: i used this wiki as a scratchpad for gathering initial related work
... battery status is in Firefox

Josh_Soref: i think it's in BB10

anssik: it's probably there

fjh: how will we interop test Firefox / BB10 ?
... will we use those implementations?

anssik: we have ready made tests
... i ran them on FirefoxOS

<gmandyam> +q

fjh: do you have a link to an output report?

anssik: i don't have one, unfortunately
... are you planning to create a document for this
... what's the minimum required output?

fjh: IMO, it's best if you have a document w/ test cases, and a summary of results of interop on the platforms
... making it excruciatingly clear
... you could legally per process use a wiki

dom: that matches what other groups are doing
... a big table w/ a row per test, and a column per implementation
... indicating pass/fail/partial

fjh: first thing is identify which tests
... and which engines
... right now it isn't clear

gmandyam: i presented to this group a couple of months ago
... anssik 's test suite is pretty good
... the problem IMO is
... on handheld devices, you have a native api
... and if the browser api doesn't follow the native api closely, that's a problem
... but you can't track that in an automated way
... i realize there are other apis where you could make that argument as well
... e.g. proximity
... human intervention when you're dealing w/ sensors is necessary

fjh: 1. is the spec doing functionally what it says it is
... 2. we want to validate that information our api provides corresponds to another reference set of info for the device
... for battery, it's the system
... for bandwidth, it's ...
... there's a theme
... we want to ensure that information provided by our spec has reasonable accuracy

gmandyam: yeah
... and similarly for e.g. proximity .. is the host device in proximity to an external object

fjh: it might not matter for some specs, e.g. ambient light
... we might want to record this when we do the testcase document
... indicate if we care if it's consistent or not
... my goal is to know which implementations we can use for interop
... which i think involves getting the implementer owner to step up
... we need to be clear up front about what we can share
... some vendors might not like having failures identified publicly
... we'd want explicit ok in advance
... for Firefox, i think we'd need an owner from their team
... but if it's in the Wild, then we can just use it
... i'm used to having things that are under development.
... but maybe for shipping it doesn't matter
... so, anssik will update the wiki a bit
... can gmandyam update it a bit?
... Josh_Soref ?
... Josh_Soref, are you volunteering to do interop for BB10?

Josh_Soref: the BB10 10.1 browser is public and could be tested
... but I should probably contact our engineering team before publishing anything...

lgombos: on what Josh_Soref said
... there are two things, the Marketing Announcement
... "Company X and Browser Y is supporting a set of APIs"
... and then there's the more formal "we pass 100%"
... those are separate
... for the more formal ones
... it could be important to let the company run it themselves
... this is also feedback from Microsoft
... if someone runs them and microsoft runs it themselves
... and you don't get the same results
... i think what fjh was asking is can we do the more formal stuff for blackberry
... for me, i think it's the same with Samsung, as it is for BlackBerry
... i could do it for Samsung, but only when the device is shipping

fjh: IME, first you do informal interop testing in the WG
... you agree w/in the DAP WG to do interop tests informally
... maybe you're identifying bugs in the tests
... if necessary, you do stuff offlist or on members-list
... and then, once we've reached a point of comfort/made progress
... then we can be more formal about it
... and then we could publish a report where everyone passes
... we want to do things informally in the group

dom: the point of CR testing is to check that an API can be implemented in the relevant software
... it isn't conformance testing
... if you choose not to relay exact values
... e.g. in battery, e.g. for privacy/security reasons
... that's beyond scope of what we need to prove for CR

fjh: Josh_Soref, lgombos, this might change what you think you can do

lgombos: i'm not really sure about the status of test suites
... if there's a test suite available, i could look into running it
... and then figure out how to share results

Josh_Soref: +1
... part of the problem is finding the test suites, sometimes there were tests in contrib/ folders

fjh: they should be linked from the interop page

dom: hopefully soon they'll be moved to the w3 github test repo
... hopefully i'll do that tomorrow

fjh: the test cases are linked from the roadmap

http://w3c-test.org/dap/battery/tests/

Josh_Soref: has submissions/
... which is odd

fjh: yeah, the structure is odd, it's anssik 's submission and not a WG test case

dom: at some point, we need to take them and accept them
... the best thing to do is after running them and decide if they work, and then accept them
... personally, i've looked at them, and think they should be accepted
... but we need to let people run them and decide if they're ok
... the submissions/ directory is only an indication that we need implementation feedback
... not that they're wrong
... the directory name will disappear in the migration

fjh: i don't think we need to wait until we go to github

lgombos: there was a Tizen developer conference last week
... where Samsung gave out Tizen developer devices w/ Tizen 2.1
... and that could be used

<fjh> test cases are linked from roadmap http://www.w3.org/2009/dap/#roadmap

<fjh> way forward may be for potential interop participants to review test cases, give feedback, consider interop within DAP (either member only or public) etc

<fjh> ACTION: fjh to check on Media Capture TPAC F2F plans [recorded in http://www.w3.org/2013/05/29-dap-minutes.html#action02]

<trackbot> Created ACTION-635 - Check on Media Capture TPAC F2F plans [on Frederick Hirsch - due 2013-06-05].

fjh: in the back of my mind is whether we'll meet at TPAC
... and how effective we'll be
... i want to be sure that we're well along the way to move forward at TPAC

Josh_Soref: i just sent an inquiry about the tests to our team

fjh: i want us to do everything possible to make sure the test cases are reasonable and help us get to CR
... i don't know you're situation, gmandyam, dcheng3
... anssik: if you could update the wiki

Action Review

fjh: the open actions are well understood

<fjh> ACTION-523?

<trackbot> ACTION-523 -- Anssi Kostiainen to work on test cases for battery, vibration, and HTML Media Capture -- due 2012-08-31 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/523

fjh: anssik 's test cases, and dom 's moving them to git

<fjh> ACTION-621?

<trackbot> ACTION-621 -- Anssi Kostiainen to create test cases for HTML Media Capture -- due 2013-03-13 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/621

<fjh> ACTION-625?

<trackbot> ACTION-625 -- Dominique Hazael-Massieux to move DAP tests to Git, with help from others as needed -- due 2013-05-01 -- OPEN

<trackbot> http://www.w3.org/2009/dap/track/actions/625

<fjh> pending

fjh: we can close pending review items

<fjh> ACTION-632?

<trackbot> ACTION-632 -- Frederick Hirsch to follow up on implementation status for DAP specifications -- due 2013-05-29 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/632

<fjh> did this, as noted in previous discussion

<fjh> ACTION-633?

<trackbot> ACTION-633 -- Frederick Hirsch to start CfC to shelve Network Information API, first checking with editor -- due 2013-05-29 -- PENDINGREVIEW

<trackbot> http://www.w3.org/2009/dap/track/actions/633

fjh: i checked w/ the editor, mounir , he's checking w/ google and others
... rather than having a CfC, i think we need to wait a bit
... i don't want to leave stuff sitting,
... i want to make clear that we're progressing or shut it down
... it seems like things are still happening

<fjh> close ACTION-632

<trackbot> Closed ACTION-632 Follow up on implementation status for DAP specifications.

<fjh> close ACTION-633

<trackbot> Closed ACTION-633 Start CfC to shelve Network Information API, first checking with editor.

Issue Review

<fjh> ISSUE-128?

<trackbot> ISSUE-128 -- Need more description on how bandwidth should be estimated -- open

<trackbot> http://www.w3.org/2009/dap/track/issues/128

fjh: i had offline discussions, i think we should keep it open

Other Business

anssik: the charter is expiring

fjh: i usually ignore that
... i think that's a simple matter of a charter extension

<fjh> http://www.w3.org/2011/07/DeviceAPICharter

<fjh> I recommend a charter extension

anssik: is the group thinking of adding anything at this point?
... there's still room to do work around sensors
... i've heard some people
... and based on discussion on the list
... that people had interest in doing something around that

fjh: i think a charter extension is a simpler thing, you extend the timeline
... you don't change scope
... i think expanding the scope would be a mistake for many reasons

dom: i'd concur
... at this time, i haven't heard a need for a rechartering
... for adding new work items
... it sounds like it'd be fair to ask the WG ML about this
... if we do ask for an extensions, which i think we'd need to
... we'd need to decide how much of an extension (how long)
... and we'd need to provide an updated set of milestones for deliverables
... so W3M can decide if the requested extension is realistic

fjh: what do you want me to say to the ML?

dom: stay close to the facts
... that the charter is expiring in July
... and say how long an extension could be, and ask for feedback
... that people could ask for longer, shorter, close or other feedback

fjh: is this a CfC?

dom: i don't think a CfC has any formality
... i think since this is the future of the WG, using a CfC isn't unreasonable

<fjh> ACTION: fjh to send public list regarding consensus regarding charter extension [recorded in http://www.w3.org/2013/05/29-dap-minutes.html#action03]

<trackbot> Created ACTION-636 - Send public list regarding consensus regarding charter extension [on Frederick Hirsch - due 2013-06-05].

fjh: ok, i'll do this

anssik: it's ok if someone wants to start work on a new sensor, that's in scope
... the group is happy to do that

dom: at the high level, yes

<fjh> need a concrete proposal, but in scope

dom: i think a concrete proposal would have to be evaluated by the WG

anssik: how would you do that evaluation in practical terms?
... i know people were eager to do it
... it seems the hardware is getting more capable in terms of sensors
... those could be fairly small additions

fjh: we need a concrete proposal

dom: i see no reason... you could assert a specific geolocation technology is a sensor
... and is in scope
... it might not be in scope, as we have a geolocation group
... in practice, each proposal gets reviewed under its own strength

anssik: we'd ask people to give proposals as member submissions
... would something less formal than that be ok?

dom: any WG participants can propose to start work on a topic in scope for the charter
... that proposal can include a concrete submission

fjh: i'd suggest that geolocation shouldn't be included
... there's already a WG, and there could be IPR issues

anssik: i agree w/ fjh on that, we should exclude geolcation from this discussion
... does anyone remember any proposals other than sensors?

fjh: we shelved Contacts, Calendar

anssik: they're mostly handled by SysApps
... then there's Intents, also shelved

fjh: Network Information
... Network Discovery
... there's still promise in Intents/Activities, just a resourcing problem
... i think there's little stuff buried in the charter

dom: we'd need to agree on a duration and get a timeline
... not sure how to do that

fjh: i'd recommend a year and a half
... too short, you go through the exercise again
... make it Dec 2014

dom: i think it'd be fine to do 18 months
... but substantiated by an updated timeline for existing deliverables
... if we expect to finish in 6 months or 24, then it doesn't make sense to ask for 18

fjh: i can do a SWAG
... say everything works out great, getting to CR this year
... still need to spring/summer of next year to get to REC
... roughly, we'd get things by May
... for Web Activities, there's no way to know
... but even for simple things like Vibration/Battery, i think it's well into fall

dom: i think that's a good starting point
... if you could include that in your email

fjh: yes, i'll include it so we get comments
... thanks anssik for raising this point

AOB

fjh: thanks for your time, this was a productive call
... if you're implementing, please review the test cases
... if you haven't looked at the latest drafts of vibration, proximity, and light, please do
... if you're following Media Capture, please look at that stuff
... also Media Recording
... and i'll send a message on charter
... and please update the implementation wiki if you can
... thanks all, see you next week

anssik: which is the canceled call?

<fjh> 26 June 2013, CANCELLED

<fjh> http://www.w3.org/2009/dap/minutes.html

[ Adjourned ]

trackbot, end meeting

Summary of Action Items

[NEW] ACTION: anssik to update introduction of vibration to refer to notification API [recorded in http://www.w3.org/2013/05/29-dap-minutes.html#action01]
[NEW] ACTION: fjh to check on Media Capture TPAC F2F plans [recorded in http://www.w3.org/2013/05/29-dap-minutes.html#action02]
[NEW] ACTION: fjh to send public list regarding consensus regarding charter extension [recorded in http://www.w3.org/2013/05/29-dap-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009-03-02 03:52:20 $