See also: IRC log
<trackbot> Date: 03 February 2010
<scribe> scribenick: conrad
PROPOSED to accept the minutes of the 27 January 2009 telecon:
RESOLUTION: to accept the minutes of the 27 January 2009 telecon
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
venue and location are booked by thierry and erik
erik: over the next 2 weeks we will have to fill in the agend
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
Raphael to fix the weird character in the spec document
3.1 Media Fragment URI syntax: (Yves)
Bug in the npt specification:
erik: we changed from abnf to ebnf (?) yves, is your action still valid?
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
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:
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
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
<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
<jackjansen> conrad, I'd like a note "for test implementation" or something.
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
erik: any news?
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]