See also: IRC log
<trackbot> Date: 23 May 2012
<scribe> Scribe: Josh_Soref
[ None ]
<fjh> Approve minutes from 16 May
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012May/att-0248/minutes-2012-05-16.html
RESOLUTION: Approve minutes from 16 May
<fjh> CfC: http://lists.w3.org/Archives/Public/public-device-apis/2012May/0206.html
<fjh> proposed RESOLUTION: Publish updated WD of HTML Media Capture, draft at http://dev.w3.org/2009/dap/camera/
fjh: AnssiK, any concerns?
AnssiK: no concerns
RESOLUTION: Publish updated WD of HTML Media Capture, draft at http://dev.w3.org/2009/dap/camera/
fjh: AnssiK, are you in a position to do publication?
AnssiK: probably
... i just need to know what to do
... roughly update the state to WD?
fjh: you change the state to WD
... run through link checker
... pub-rules checker
... validity checker
dsr: I can help with the publication
<darobin> ACTION: anssi to prepare WD of HTML Media Capture [recorded in http://www.w3.org/2012/05/23-dap-minutes.html#action01]
<trackbot> Created ACTION-539 - Prepare WD of HTML Media Capture [on Anssi Kostiainen - due 2012-05-30].
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012May/0239.html
<fjh> proposed RESOLUTION: Drop drafting recharter of DAP (v3)
fjh: any reason not to do it?
... darobin, you spelled it out on the list
darobin: i think given the limited extension of scope
<fjh> proposed RESOLUTION: Drop drafting recharter of DAP (v3)
darobin: i don't think it's worth the effort
<darobin> +1
RESOLUTION: Drop drafting recharter of DAP (v3)
<fjh> Further draft updates: http://lists.w3.org/Archives/Public/public-device-apis/2012May/0231.html
<fjh> clarification of events (bubble), http://lists.w3.org/Archives/Public/public-device-apis/2012May/0232.html
<fjh> test suites/implementation http://lists.w3.org/Archives/Public/public-device-apis/2012May/0236.html (Marcos)
fjh: i think it'll be fairly straightforward to get Marcos to be an Invited Expert
... AnssiK anything you want to say?
AnssiK: not really, the discussion is going on the list
<darobin> ISSUE-113?
<trackbot> ISSUE-113 -- AddEventListener in Battery Status has side effects -- closed
<trackbot> http://www.w3.org/2009/dap/track/issues/113
darobin: I'd like to ask if we should reopen ISSUE-113
Marcos: i don't know if we should reopen it
... but there's definitely an issue here
... we have a similar side effect issue
... i think the new proposed text that AnssiK proposed is sufficient
darobin: it's fine by me
... but i just don't want a torrent of objections like we had last time
fjh: Marcos, do you want to talk about the tests you've written?
Marcos: i've just updated the work i've done there
... i think the test suite is fairly complete
... i think i may need to update the test descriptors
... from my perspective, i think they're ok
fjh: anything else to discuss here?
Marcos: i noticed the use of proximity.html document has been deleted
... from the repo
... i guess that was the right thing to do
... but i wasn't sure if that was causing confusion, with two documents
... i think myself and dougt were confused by that
fjh: maybe we should adopt the process of having source and output in the repo
... that Marcos suggested
AnssiK: what was the confusion?
Marcos: it's hard to know that something changes
... the date in the file
<AnssiK> see http://dvcs.w3.org/hg/dap/ for changes
<fjh> if we generate and store Overview.html, then that version will have fixed date and status, while Overview.src.html always runs the scripts and usually updates the date, etc, confusing
Marcos: dougt also got confused
AnssiK: the confusion happened because Dzung forked the spec
<AnssiK> http://dvcs.w3.org/hg/dap/log/bf7c4fc193cd/proximity/Overview.html
<fjh> s/jung forked/Dzung forked/
Marcos: we could include an iframe
AnssiK: including an iframe seems like a hack
... it seems like we should make this a ReSpec feature
... an iframe may be overkill
... maybe a link to the revisions
... many other specs do that already
Marcos: that's fine
... working with the document all the time, you need to be able to see everything in one go
AnssiK: you may want to subscribe to public-dap-commits
<AnssiK> http://lists.w3.org/Archives/Public/public-dap-commits/
<fjh> comments from Greg, http://lists.w3.org/Archives/Public/public-device-apis/2012May/0247.html
Jungkee: XXX
<Jungkee> Proposed metadata
Jungkee: we need to look at metadata
... fields
... all of the types
... metadata
... metadata
... I also have a Gallery demo
... i'll post the link in one or two days
... it's about data/content delivery
... so we could have some more concrete discussion
... on how we could use the delivery method
<Zakim> fjh, you wanted to ask if metadata is topic for media capture task force
Jungkee: not really
... there are two topics
... 1. metadata
... the media ontology group defined a core set
... i want to bring that set to the gallery api
... 2. data delivery methods
... we are going to deliver the content as a blob
... or because of performance issues,
... bring the metadata as a url
... after i share the demo
... we could probably see some critical concerns
... about the data delivery method
fjh: the reason i asked about the TF
... is there are two types of metadata
... 1. "Author" etc.
... 2. data delivery, which seems similar to the Constraints stuff in the TF
... what should happen next?
... what would you need to do?
Jungkee: i could have a discussion about metadata on the MC TF
<fjh> might want to review the constraints work, though I think that is too much detail for what you intend for gallery
<Zakim> Josh_Soref, you wanted to say that Media Ontology is not a "Liked" topic by browser vendors
Jungkee: i understand that browser vendors don't like it
... but
Josh_Soref: [ lots of reasons not to use Media Ontology spec ]
<darobin> [I wonder if we can just release something and ask the broader community for their input on the type of metadata they want]
Jungkee: the reason to use it
... is existing services
darobin: in general
... i think to move this forward
... it would be useful to keep the metadata discussion separate from the specification discussion
... i people aren't happy with the general approach
... there's no need to have the metadata discussion
... if people are happy with the general approach,
... then we can ask for input on metadata
... does that make sense?
fjh: i think we need to understand the metadata that matters for gallery
... and then decide how to represent it
darobin: for me, there are two aspects in the proposal
... 1. how gallery works in general
... 2. metadata in gallery
... i think it makes sense to get consensus on 1
... if people like that, then we can discuss 2
... schema.org, ad hoc, whatever
... if people don't like 1, then there's no point to discuss ontologies
Jungkee: i agree with you
... i'll share the demo
... and we can look at metadata after that
darobin: sounds like a good plan
<fjh> http://lists.w3.org/Archives/Public/public-device-apis/2012May/0250.html
fjh: darobin, i think that's on its way to AC
darobin: I made my last draft
... the name of the group has changed to System Applications
... because it shouldn't just focus on APIs
... but also the runtime environment
... there's going to be a discussion on a name for the ML
... then once W3 is happy w/ the Charter
... which they're looking at
dsr: darobin, should I create an ML?
... public-sysapps?
darobin: excellent
fjh: AnssiK, Thanks Anssi for the update to clarify the home page, changing priority apis to active
[ Adjourned ]
trackbot, end telcon