See also: IRC log
<trackbot> Date: 29 May 2013
<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
<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
<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
<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
<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
<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
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.
<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
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
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