See also: IRC log
<trackbot> Date: 08 September 2010
<erik> scribe: Silvia
<erik> ScribeNick: Silvia
<erik> Date: 08 September 2010
PROPOSED to accept the minutes of the 07 July 2010 telecon:
http://www.w3.org/2010/07/07-mediafrag-minutes.html
<erik> +1
<davy> +1
+1
accepted
LC Period: extension?
erik: should be extended till the end of the month
... we have to close everything for TPAC
Yves: extending till the end of the month beyond TPAC is good to get feedback
<scribe> ACTION: troncy to send reminders to all relevant groups [recorded in http://www.w3.org/2010/09/08-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-183 - Send reminders to all relevant groups [on Raphaël Troncy - due 2010-09-15].
erik: there will be a meeting at TPAC
... Davy, Raphael and Yves will be there - Yves can only make it on Tuesday
<Yves> http://www.w3.org/2002/09/wbs/35125/TPAC2010reg/
Discussion (Philip+Yves): media fragment syntax grammar (why segment production rule is not normative?), extensibility, pseudo algorithm code
scribe: has not yet happened
close ACTION-175
<trackbot> ACTION-175 Update the grammar parsing automatically generated code for the URI syntax closed
Yves: we need to discuss extension points
... that will trigger what we define as valid media fragments
... will have to wait until next week when we can talk with Philip
<Yves> related also to http://lists.w3.org/Archives/Public/public-media-fragment/2010Sep/0000.html
erik: we'll discuss it next week
Image sprite in HTML5: http://lists.w3.org/Archives/Public/public-media-fragment/2010May/0061.html
erik: this is related to a discussion on the WHATWG
Yves: this is about what to do in the UI with spatial media fragments
erik: the point made is that cropping is requested as the UI effect of media fragments
<raphael> please, consider the use case bring by Europeana and sent yesterday
Yves: we may need to support both, highlighting and cropping, and need to differentiate between them
davy: I think it's application-dependent
... I think we should leave that open
<raphael> ... they are very keen to implement the spec and they really would like to have a keyword in the URI that can refer to a description of any arbitrary spatial shape
Yves: in that case we are not controlling what is presented to the user
<raphael> ... the usage would not be retrieval as for the current spatial media fragment, but address and highlight on client a particular shape
silvia: the WHATWG doesn't want to specify the presentation of media fragment URIs in the HTML spec, but wants it to be in our spec
... that's where it belongs in their mind
<raphael> ... what Europeana wants is a way to address any spatial region, with a media fragment URI
silvia: yes, what raphael says - we may need to introduce another means of specifying arbitrary shapes which can then only be used for highlighting
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/026937.html
Davy: they should just use the query parameter
silvia: no, they don't want the cropping to happen on the server, they just want the effect to be specified
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/027581.html <- the key thread
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-August/028163.html
davy: do you agree with Ian?
silvia: I didn't but I think he has a point
... maybe we have to specify it and it may even apply to all applications
... or we may need to put an extra mechanism in to specify if we want cropping or highlighting
davy: or we can just specify it as cropping for the browser
Yves: it depends on the application and we need to explain that better
silvia: but the problem is that the researchers in Europe also want to use it in the browser, so it's still the same application
<Yves> effect=highlight (with a default of cropping)
silvia: maybe we should create a new scheme for arbitrary selections and they would just be for highlighting
Yves: I was thinking of adding a parameter
Davy: how does that work with multiple dimensions
silvia: we could do that in the temporal domain, too
Yves: I want Jack's input on this
silvia: this discussion is different to what we looked at before: it's only about what is being presented in the application
... we could do something like add an extension to the region, e.g. xywh=x,y,w,h_crop or xywh=x,y,w,h_highlight
erik: we need to discuss in a larger group
... this is only about how to render something, nothing to do with what goes over the wire
... this in fact relates to all three of the comments we received
Robert Sanderson: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jul/0010.html <- also
scribe: but the Chris Double comment is different
Chris Double: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0099.html
Yves: answer to Chris is: it should always send the header, because in the worst case it will send the whole resource
<scribe> ACTION: Yves to email Chris the reply on when to send the range header [recorded in http://www.w3.org/2010/09/08-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-184 - Email Chris the reply on when to send the range header [on Yves Lafon - due 2010-09-15].
Yves: Robert wants to be able to extend stuff
... the main issue is that you have no control of what you see on the other end, since the reference URI changes all the time
... this may be an issue
... apart from this, I think it's ok
silvia: I think adding extra name-value parameters to the URI is ok - that's how we built it
... but they want to change the spatial fragment spec, so that's not ok
... they should just add another name-value parameter
erik: seems we need to discuss this next week
close ACTION-182
<trackbot> ACTION-182 Include summary into wiki page closed
erik: philip cannot make it next week - let's have the grammar discussion in two weeks
... next week we will focus on the public comments
nobody here for it
erik: let's close it here