Media Fragments Working Group Teleconference

<trackbot> Date: 17 November 2010

trackbot, start telecon

<trackbot> Meeting: Media Fragments Working Group Teleconference

<trackbot> Date: 17 November 2010

<tomayac> hamburg, germany, yes

1. Admin

<scribe> Scribe: Raphael

<scribe> Scribenick: raphael

PROPOSED to accept the minutes of the 7th F2F meeting:

- http://www.w3.org/2010/11/01-mediafrag-minutes.html

- http://www.w3.org/2010/11/02-mediafrag-minutes.html

?

<erik> +1 (but am still reading it though :)

+1

<tomayac> pass ;-)

<Yves> +1

minutes accepted

2. Media Fragment Specification

For IBBT ...

ACTION-192?

<trackbot> ACTION-192 -- Davy Van Deursen to update the specification to state what the processing should do when media fragments request (time dimension) does not match exactly how the media item has been encoded -- due 2010-11-08 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/192

ACTION-193?

<trackbot> ACTION-193 -- Erik Mannens to make a schema for the server redirect recipe -- due 2010-11-08 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/193

ACTION-195?

<trackbot> ACTION-195 -- Davy Van Deursen to add a paragraph in the section 7.1 to specify that video, audio, img or any href is all treated similarly (range request issued when facing a media fragment) -- due 2010-11-08 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/195

ACTION-191?

<trackbot> ACTION-191 -- Yves Lafon to update the production rules of the time dimension with the npt format for making the hours optional -- due 2010-11-08 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/191

Yves started to do it during the f2f meeting, needs to add a sentence in the spec

ISSUE-19?

<trackbot> ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19

Philip has proposed a number of patches, see result at http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html

Yves has discussed this with Philip which sort of outdate this proposal

Yves: the result is that we should keep the grammar as it is, + some clarification text on the purpose of the grammar
... + a normative algorithm for parsing
... we need consensus and approval from Jack, Silvia, and Davy at least in the group + feedback from the implementers

<silvia> is the proposal formally specified somewhere?

<silvia> I'm probably ok with it but don't want to give a blind vote

Raphael: what this clarification text should express?

<Yves> the purpose of the grammar is to describe the "normal" syntax, ie: the one that should be created

<Yves> ie: it is not the parsing rules

Raphael: where we should write this ?

Yves: at the beginning of section 4 and appendix D
... as a reminder

<scribe> ACTION: raphael to add a clarification text regarding the purpose of the grammar [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action01]

<trackbot> Sorry, couldn't find user - raphael

<scribe> ACTION: troncy to add a clarification text regarding the purpose of the grammar [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action02]

<trackbot> Created ACTION-199 - Add a clarification text regarding the purpose of the grammar [on Raphaël Troncy - due 2010-11-24].

Raphael: regarding the parsing algorithm

Yves: back to a very detailed description of the algorithm
... I would like to read it crisp and procedural
... we need an agreement that the parsing algorithm become normative
... I would agree that given this clarification of role, the algorithm become normative

Erik: I agree too

Silvia, would you have any objection of having a detailed parsing algorithm of a media fragment URI nomative in the spec instead of an annex?

Two versions of the algorithm

scribe: 1/ http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-uri-syntax
... 2/ http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-components
... and http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-components
... and http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-lists

<silvia> no objection here

Raphael: I agree to ask Philip to put which version he prefers
... the only contentious issue might be: 2.

2. Otherwise, the name-value pair does not represent a media fragment dimension. Validators should emit a warning. User agents must ignore the name-value pair.

Note: Because the name-value pairs are processed in order, the last valid occurence of any dimension is the one that is used.

Raphael: Validators should perhaps emit an error rather a warning ?
... the processing order of the dimensions and whether parsing should be relaxed or not in case of multiple occurences of the same dimension (except track)

<scribe> ACTION: troncy to send a proposal to close ISSUE-19 that consists in: clarification text + normative parsing algorithm [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action03]

<trackbot> Created ACTION-200 - Send a proposal to close ISSUE-19 that consists in: clarification text + normative parsing algorithm [on Raphaël Troncy - due 2010-11-24].

<foolip> I prefer my latest version that uses the namevalues syntax

great, thanks Philip, we will use this one then :-)

3. Media fragments URI on web page

Raphael: started by a thread from Silvia
... discussed at the F2F meeting: http://www.w3.org/2010/11/02-mediafrag-minutes.html#item05
... lead to the notion of optimistic use of the Range header, only for the 'second' unit
... it cannot be done for any other way for getting part of the content

<silvia> (except that my email was about something completely different ;-)

<Yves> yeah I think Silvia's email was about using the html fragment for video

<Yves> which by default is => no (ie: it's per page, so you can't generalize this)

<silvia> it was not to become normative - the idea is to propose a syntax that people can choose to make use of

<silvia> because the html URI is much more important for most video on the web than the video URI

Yves: there are 2 orthogonal issues
... the fragment applies to ONE resource you're retrieving
... if you want the fragment on the page be applied to the video element on that page, this is your javascript that can do that, nothing to put in the spec
... the other issue of optimistic use of the Range header, Philip states that this is up to the URI spec to change
... I quote: "The semantics of the fragment identifier is defined by each MIME type registration. Before we know the type, we can't assume anything. Therefore, the only possibility is if the URL/URI/IRI spec itself states that #t=1 has some semantics for *all* types and that this should cause headers Foo and Bar to be sent. However, I truly doubt we'll see media-specific things like this put into URL/URI/IRI, it's seems like a gigantic layering violat

<silvia> as I said: the idea is to give a Web developer that wants to do media fragments on a Web page a recommendation for how to do the URI structure on their page - they still have to implement it themselves, it's just handy to agree on the same approach

<silvia> no need for more Range headers, or an implementation in browsers or anything - just a helping hand for Web developers

Raphael: I agree silvia, and I strongly recommend to add a new Appendix for what you propose, note to developers :-)

<foolip> Agreed, as long as there's no change in UA behavior for #t=1 for HTML I'm fine with recommending web developers to use the syntax

<silvia> btw: all the video hosting sites already have such approaches in the URIs so it's not theoretic

<Yves> I agree that we can't assume anything, and we shouldn't break any layer, but if we know enogh context, using Range request with a unit that can only be applied to the media type we are targeting (and will default to normal behaviour for all the others)

Silvia, would you like to have an action to write a paragraph, note to developers, that they can easily implement a javascript to forward the hash on the URI to the video element?

<Yves> is a (not nice) possible optimisation

<silvia> yup, no problem

<silvia> just don't know when I'll get around to it :)

<Yves> context should be that URI is in a <video> tag

<silvia> sure

<scribe> ACTION: Silvia to write a paragraph, note to developers, that they can easily implement a javascript to forward the hash on the URI to the video element [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action04]

<trackbot> Created ACTION-201 - Write a paragraph, note to developers, that they can easily implement a javascript to forward the hash on the URI to the video element [on Silvia Pfeiffer - due 2010-11-24].

Raphael: it is part of my action to clarify the use of optimistic use of Range header optimization in case we are in the right context <audio> or <video> element

4. AOB

Erik: what is the schedule?

<Yves> erik, http://www.w3.org/2005/10/Process-20051014/tr.html#Reports

Raphael: finish all actions in the tracker by the end of the month, so we can transition to CR
... have a telecon about test cases afterwards, for preparing the exit CR stage

<erik> horay for Thomas!

<tomayac> thanks :-)

<tomayac> http://tomayac.com/semwebvid/

Raphael: we have discussed Ken Harrenstien
... from YouTube

<tomayac> funny enough ken and me have already been in contact with regards to YT closed captions. i'll catch up with him and let him know about recent developments.