W3C

- DRAFT -

Media Fragments Working Group Teleconference

03 Feb 2010

Agenda

See also: IRC log

Attendees

Present
conrad, davy, erik, silvia, thierry, yves, jack
Regrets
davy, raphael, michael
Chair
erik
Scribe
conrad

Contents


<trackbot> Date: 03 February 2010

<scribe> scribenick: conrad

1 Admin

PROPOSED to accept the minutes of the 27 January 2009 telecon:

<silvia> +1

<jackjansen> +1

<erik> +1

RESOLUTION: to accept the minutes of the 27 January 2009 telecon

ACTION-127

Thierry/Yves to look for the charter extension

extension has not yet been granted, but should not be an issue -- just w3 process

Erik: submission of MTAP SI on Semantic Multimedia ongoing

<tmichel> the extension should have discussed at last week W3M meeting, but is was not

2. F2F meeting

<tmichel> plh said it should be discussed this afternnoon

Draft Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/FithF2FAgenda

venue and location are booked by thierry and erik

erik: over the next 2 weeks we will have to fill in the agend

a

we have to go to last call in march, there is a lot to discuss, it will be important

there will be 5 there, hopefully the others can attend via phone

3. SPECIFICATION:

Raphael to fix the weird character in the spec document

<scribe> CLOSED: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jan/0102.html

3.1 Media Fragment URI syntax: (Yves)

Bug in the npt specification:

Philip: http://lists.w3.org/Archives/Public/public-media-fragment/2009Nov/0023.html

Dom: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jan/0093.html

erik: we changed from abnf to ebnf (?) yves, is your action still valid?

yves: yes

silvia: is there an issue with the change?

yves: no, i am using abnf for other things, but i'm sure ebnf shall be similar

silvia: then we only have the parsing issues dom mentioned, which are minor

yves: the npt definition was not exactly correct, that was the only thing holding up the grammar

silvia: yes, as discussed in email, just a small change

yves: i will look at that before the f2f

(but i will be away next week)

3.2 Protocol for URI fragment Resolution in HTTP

Erik: any problem with the changes proposed by Philip?

silvia: no, they clarify things, they might have made the document structure more complicated. philip also proposed some changes to document structure but they make sense

erik: i agree

jackjansen, i would be against a structure where normative and non-normative are not separated. I would like them to be clearly spaced

silvia: we should put an overview table at the end of the document of what is normative and informative, rather than spreading it through the document. most of it is obvious, but it is important to put the info in one place

jackjansen, the nice thing about a table is that if it indexes all the normative stuff, you can use it to find what you actually need

jackjansen, not sure i like the idea that it should be clear from the wording, because then in non-normative text you have to refrain from using SHOULD, MUST etc.

jackjansen, it should be clear from the layout which is which

silvia, comments in-line about what is normative is not useful

jackjansen, in SMIL spec, we put in text markers for people who use screen readers etc. (as well as colors)

jackjansen, in the published document there are only text markers -- the visual markers were not included

silvia, make a note now, put these in if we come to committee draft

jackjansen, the xml format we use has a way to distinguish paragraphs, so if we use that we can modify the layout in stylesheet

thierry, distinguish in screen and aural?

jackjansen, just use the xml to make a clear distinction between normative and informative text

<tmichel> http://www.w3.org/TR/2008/REC-SMIL3-20081201/smil-structure.html

thierry: we should put a div with class="normative" or class="informative"

<scribe> ACTION: Erik to mark up the spec with normative and informative classes [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action01]

<trackbot> Created ACTION-134 - Mark up the spec with normative and informative classes [on Erik Mannens - due 2010-02-10].

thierry: do we also want to have text saying "this section is normative"?

silvia, that can be part of the style

silvia, i guess the table is already in the document, but a table at the end with a reference to the normative parts would be nice

ACTION-123: Yves to come up with ABNF for header syntax

<trackbot> ACTION-123 Come up with ABNF for header syntax notes added

erik: action 133 is ongoing

yves: re: action 123, need to find the proposal from the archives

Review of the complete Section 5.2.1 for group approval

<scribe> postponed (we have not all yet reviewed it)

erik, this should be done before the f2f

silvia: i have read it and am happy with it, apart from minor issues in the ebnf; dom also suggested to put the ebnf syntax together in one place; maybe we should just repeat it all at the end

silvia, he made a few changes to make it easier to read, along the lines of the html5 spec

silvia: i'm happy with what he's done, i don't have any issues

erik: ok, tbc

3.3 Rendering of Media Fragments URI in UA:

ACTION-130

Silvia to draft a new subsection in the Section 5 regarding the rendering in the UI of media fragments, at least for the temporal dimension

silvia: i sent an email just before this meeting
... i've put a paragraph into section 5.1.4

<silvia> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-overview-interpretation

so basically the action is done

silvia: davy, i've made a mention of spatial,track dimensions

davy: ok, i'll work over that too

jackjansen, i really like silvia's suggestion, but we should make sure that in the protocol we have enough detail to actually implement it

jackjansen, which touches on issue 5, similar to silvia's note about the temporal domain, but in the spatial domain

jackjansen, we should ensure that the server provides any information such as width, height etc. so that clipping can be implemented client-side

silvia, we need to specify these things for each dimension, please add a paragraph

jackjansen, also at the end of section 5.1.4, a very simple graphic of a timeline of a video playing would be handy to help with understanding the intention

close action-130

<trackbot> ACTION-130 Draft a new subsection in the Section 5 regarding the rendering in the UI of media fragments, at least for the temporal dimension closed

<scribe> ACTION: davy,erik to extend section 5 regarding spatial and track dimension [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action02]

<trackbot> Sorry, couldn't find user - davy,erik

<scribe> ACTION: erik to extend section 5 regarding spatial and track dimension [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action03]

<trackbot> Created ACTION-135 - Extend section 5 regarding spatial and track dimension [on Erik Mannens - due 2010-02-10].

<scribe> ACTION: davy to create a diagram of video timeline to explain temporal dimension [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action04]

<trackbot> Created ACTION-136 - Create a diagram of video timeline to explain temporal dimension [on Davy Van Deursen - due 2010-02-10].

<scribe> ACTION: jack to check that 5.1.4 is implementable using the protocol [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action05]

<trackbot> Created ACTION-137 - Check that 5.1.4 is implementable using the protocol [on Jack Jansen - due 2010-02-10].

3.4 Discovery of 'Track' and 'Named' fragments:

silvia: nothing to discuss yet, this is being worked on in ogg

3.4, 3.5 to be discussed later on

5. TEST CASES: (Michael)

erik: i'm in favour of making next phone conf all about test cases, for a whole hour

silvia, last week we mentioned that the foms people would be keen to have an indication on which sections are fairly ready, and my suggestion was that section 5.2.1 can be implemented

<Yves> the only indication of stability is publishing LC or CR

conrad: perhaps we don't need to specify that the mechanism for handling client-side fragments involves http byte-range requests: just specify that "if the client can already seek over the network, honor this fragment syntax"

silvia, last week we decided that rather than pulling out parts of the document which are stable, we simply mark within the document how mature each part of the document is, so implementers can go ahead

silvia, whereas last call etc. is really for the whole document; we don't want to hold back implementers

Yves, the parts which are unstable may lead to changes in the parts we think are stable now

silvia, unlikely as that section is really trivial

jackjansen, that section has very little value with out parts of chapters 3, 4

jackjansen, i like the sentiment about allowing implementers to start implementing stuff, but ...

silvia, yes, but we have already been through section 3 substantially, any changes will be minor

jackjansen, i probably agree, but then even if we mark sections as "stable" we should specify that it may change anyway. we don't want to be editing for all eternity like the whatwg is doing

silvia, we should start having implementations. we are really close to having the temporal stuff finalized, even though the headers etc. may still be under discussion

silvia, if we keep working on the spec without any implementations, it's not going to move ahead in a reasonable amount of time

jackjansen, if we mark these things as not "stable/unstable" but "reaonsably stable, mature" etc. that is fine with me

silvia, "ready for test implementations" would be a useful indication

erik: fine by me too

4. ISSUES

<jackjansen> conrad, I'd like a note "for test implementation" or something.

issue-4.1

erik: postpone non-active issues

5. TEST CASES

jackjansen, is a phone conference the best medium for discussing details of test cases?

silvia, i agree -- we should prepare the group for the meeting re: test cases, but it is up to michael

silvia, whether we prepare for the test cases next week or not, we should at least talk about it then

6. IMPLEMENTATION:

erik: any news?

none

all ongoing

7. AOB

none

Summary of Action Items

[NEW] ACTION: davy to create a diagram of video timeline to explain temporal dimension [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action04]
[NEW] ACTION: davy,erik to extend section 5 regarding spatial and track dimension [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action02]
[NEW] ACTION: erik to extend section 5 regarding spatial and track dimension [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action03]
[NEW] ACTION: Erik to mark up the spec with normative and informative classes [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action01]
[NEW] ACTION: jack to check that 5.1.4 is implementable using the protocol [recorded in http://www.w3.org/2010/02/03-mediafrag-minutes.html#action05]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/02/03 11:01:13 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/davy/thierry/
Found ScribeNick: conrad
Inferring Scribes: conrad
Present: conrad davy erik silvia thierry yves jack
Regrets: davy raphael michael
Agenda: http://lists.w3.org/Archives/Public/public-media-fragment/2010Feb/0000.html
Found Date: 03 Feb 2010
Guessing minutes URL: http://www.w3.org/2010/02/03-mediafrag-minutes.html
People with action items: davy erik jack

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]