See also: IRC log
<trackbot> Date: 23 January 2013
<scribe> Scribe: Josh_Soref
<fjh> Welcome, Shuning, CNGI, http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0050.html
<fjh> No call next week - 30 January 2013 teleconference has been cancelled. Next call 6 Feb.
<Zakim> dom, you wanted to note that Feb 6 overlap with WebRTC WG (although not necessarily media cap stuff)
fjh: propose canceling 13th
dom: no objection
... on feb 6th, if there's a meeting, i'll have to send regrets
... the Media Capture F2F will also include the 6th
fjh: i was confused about the schedule
dom: my understanding is MC will include Wednesday morning Eastern Time
<gmandyam> Isn't there a joint meeting between Media Capture TF and WebRTC during the interim?
Josh_Soref: i think there are enough attendees
gmandyam: I will be attending
fjh: i was thinking of just stepping out for a brief call
<fjh> proposed RESOLUTION: cancel 13 Feb teleconference
RESOLUTION: 13 Feb teleconference is canceled
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/att-0026/minutes-2013-01-16.html
RESOLUTION: Draft minutes from 16 January 2013 are approved.
<fjh> "the LightLevelState enum needs to have an empty string value. Right now, the spec is inconsistent with the IDL, as it says to sometimes set attributes that are typed as LightLevelState to the empty string, but that is an invalid value." http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0039.html (Tab)
<fjh> Duplicate Attribute definitions
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0049.html
fjh: AnssiK, so you found and fixed a bug which related to duplicate generation?
AnssiK: yes, and i submitted a pull request, and it was integrated
fjh: so it's live?
... yes, i see that section is gone
... some things are on Navigator, and some are on Window
... anne asked why Window
... is this an oversight or intentional?
AnssiK: my understanding is that
... anne meant whether we restricted to top-level-browsing context
... i have to send an email to anne
... i looked at Gecko's code
... it should be browsing context window object
... basically Background tabs/windows wouldn't get notifications
... let's see what dougt says
fjh: and why do we use navigator/window?
AnssiK: i think it's historical reasons
... Window is used for event because DeviceOrientation used it
fjh: it seems Navigator makes more sense overall
AnssiK: for events, Window has been the place
... other APIs following the GeoLocation pattern have used Navigator
fjh: what about Battery?
AnssiK: it's a hybrid
... a sync API and event handlers
... bike-shedding where these should live is fun
... but Rick is getting up to speed
... and he'll create a new proposal for sensors
fjh: i think it's important for usability/consistency over time
... i think at some point there will be an issue getting things over time
... if implementers don't have a deep concern, then we don't have a reason to change
... if anyone has a concern, please comment on the list (or call)
... thanks AnssiK
... i'll close the LC issues
... oh, and Queuing
... AnssiK, did you do something for that?
AnssiK: yes
<fjh> in the process of following up with Greg and Mounir to determine status of their work with WebIntents
<fjh> Declarative Invocation - some interesting thoughts on the list
<fjh> issue with proposed change of work venue however, http://lists.w3.org/Archives/Public/public-web-intents/2013Jan/0010.html
fjh: he sent a provocative message
... i sent a reply saying it wasn't a good idea
... there was a private +1 from the team
... i think that message of his is moot
... i think he has ideas on Declarative that might be helpful
dom: i agree, the issue is moot
... i wouldn't even call it an issue
... it's good that you clarified that to him
... the lack of activity in the TF is worrisome
... i hope we'll see movement in this space soon
fjh: the work is really the work of the entire TF
... mounir and greg are really implementers
... Claes, you're also involved
... i don't want to throw your work away either
Claes: thinking about what's happening here
... greg stated there were usability issues
... there wasn't clear action
... i think we need a clear statement from those guys
fjh: i think we need to look more closely at the declarative stuff that fred was talking about
... fred had some ideas
... jhawkins said why don't you make a proposal
... and fred made something more detailed
... we need to figure out how to get this going forward
fjh: we're talking about mid-may possibly
... i have a reservation for burlington, ma, but we were there before
... i know dcheng3 is looking
dcheng3: nothing new to share
... i'll give a shout when i get an answer
... in London we have room for 20
fjh: and bryan is also looking
dom: one of the main values of the F2F is making progress on Web Intents
<fjh> we need a clear goal for F2f, eg. webintents
dom: and making sure we're aligned
... if we have no clear path, then i'm not sure the F2F would provide useful input
... the two seem strongly bound
<fjh> 5-7 February F2F, Bedford MA, registration and logistics, http://lists.w3.org/Archives/Public/public-media-capture/2013Jan/0055.html
<fjh> MediaStream Recording draft: https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/MediaRecorder.html
<fjh> Media Capture and Streams: http://dev.w3.org/2011/webrtc/editor/getusermedia.html
fjh: there's a CfC coming
... for recording
... and i'll forward it
gmandyam: i voiced an objection to that in the TF
... i've asked the editors to clarify who owns the deliverable
... afaict it should be documented in the charter
... their text seems to indicate it's owned by the webrtc
dom: i understand your concern
... i think it just was forgotten in all the work they have to do
... it's understood it's a joint-deliverable
... the bug will be fixed as soon as possible
<fjh> expect to have CfC for Media Stream Recording, will forward to this wg as well
gmandyam: my understanding is that Charter should be clear
... the MC TF just has an email from robin as a charter
dom: TFs don't exist in W3 process
... the charters to look at are WebRTC and DAP
... if you don't find something that covers that deliverable, then that's something worth an objection
... i will note that objecting to FPWD on technical grounds isn't usual
... the FPWD is just to roughly scope the work
... it isn't meant to be technically finished
... it's just setting a stake to the ground
gmandyam: when i give objections, it isn't about semantics, it's about scope/ip
fjh: i think it should say in Status that it's a deliverable of DAP+WebRTC
... it doesn't say that now
... dom's right, everything can change
... but that's something the chairs should respond to
... this is a heads-up
... it will be cross-posted
... i'll send a message about the status section. i think that should be corrected
fjh: we published ReSpec ED recently
... which caused dates to change
... if you have problems w/ ReSpec with your browser, then you can't view the document
... i think editors should check in a version of the document that everyone can view
... tobie agrees with that
... tobie suggested dated versions
<bryan> +1
fjh: i don't think it's a big deal for editors to check in the resultant document
... does anyone object to this?
... and maybe have our current documents updated to have an html version on the homepage?
... AnssiK ?
<Zakim> dom, you wanted to note I could automate that if needed
dom: i don't disagree in principle
... i think having a static document is helpful in many cases
... it's helpful for my webidl checker
... i think it's important that we not spend editors' time
... on menial tasks
... i think it should be fairly simple to automate
... if we have a convention for filenames
<fjh> It is important to remember that a little time of the editor can save the time of many readers
dom: then i could have a script to generate the resultant file
AnssiK: i think we should automate it
... if you do multiple minor edits, then it's a lot of work
fjh: if you have 1 editor and 1000 readers
... then saving time for 1000 people is valuable
... if you don't version the name of the file, it doesn't take much time
... but if dom can automate this, then editor's don't have to deal w/ it
... which would be a win-win for everyone
<dom> ACTION: Dom to look at automating generation of static docs out of respecs docs [recorded in http://www.w3.org/2013/01/23-dap-minutes.html#action01]
<trackbot> Created ACTION-611 - Look at automating generation of static docs out of respecs docs [on Dominique Hazaël-Massieux - due 2013-01-30].
fjh: i think editors should spell-check, validate, link-check
dom: i agree editors have a responsibility to keep their document clean
... but it's one thing for TR/
... but another thing for ED/
... i'd rather keep ED/s as up-to-date as possible
fjh: i'm not sure how to automate this
... i guess you could do this in ReSpec
... if you automate it, we should make sure other groups could take advantage of it as well
dom: i'll look into it
... and possibly make it available to other groups too
fjh: i'm not going to go through actions
<fjh> http://www.w3.org/2009/dap/track/actions/open
<fjh> http://www.w3.org/2009/dap/track/actions/pendingreview
<fjh> ACTION-523?
<trackbot> ACTION-523 -- Anssi Kostiainen to work on test cases for battery and vibration -- due 2012-08-31 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/523
AnssiK: when i get a device
fjh: we won't meet next week
... we might meet the following week
... thanks for your time
... gmandyam, i don't understand your technical bits, you'll need to followup with the TF chairs
... thanks Josh_Soref for scribing
trackbot, end meeting