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.
s|s/development/development.||
scribe: but maybe for shipping it
doesn't matter
... so, anssik will update the wiki a bit
... can gmandyam update it a bit?
... Josh_Soref ?
fjh: Josh_Soref, are you volunteering to do interop for BB10?
Josh_Soref: the BB10 10.1 browser
is public and could be tested
... ZZZ
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 Hazaƫl-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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Present + Frederick_Hirsch// Succeeded: s/fjh: we've agreed to wait until the end of may before responding// Succeeded: s/develoment/development./ FAILED: s|s/develoment/development.|| Succeeded: s/develoment/development/ Succeeded: s/.../anssik:/ Succeeded: s/realisitc/realistic/ Succeeded: s/calll/call/ Succeeded: s/youcan/you can/ Found Scribe: Josh_Soref Inferring ScribeNick: Josh_Soref Default Present: Josh_Soref, fjh, dcheng3, +1.214.919.aaaa, gmandyam, lgombos, milan_patel, dom, anssik Present: Josh_Soref fjh dcheng3 +1.214.919.aaaa gmandyam lgombos milan_patel dom anssik Frederick_Hirsch Diana_Cheng Milan_Patel Dominique_Hazael-Massieux Anssi_Kostiainen Laszlo_Gombos Regrets: Bryan_Sullivan Agenda: http://lists.w3.org/Archives/Public/public-device-apis/2013May/0070.html Found Date: 29 May 2013 Guessing minutes URL: http://www.w3.org/2013/05/29-dap-minutes.html People with action items: anssik fjh[End of scribe.perl diagnostic output]