See also: IRC log
<trackbot> Date: 17 February 2010
Silvia, are you planning to join?
<mhausenblas> ACTION-140?
<trackbot> ACTION-140 -- Michael Hausenblas to create a more readable version of the TC classification at http://www.w3.org/2008/WebVideo/Fragments/TC/mftc -- due 2010-02-17 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/140
<mhausenblas> http://www.w3.org/2008/WebVideo/Fragments/TC/
Accept the minutes at http://www.w3.org/2010/02/10-mediafrag-minutes.html
<mhausenblas> +1
+1
<jackjansen> +1
F2F Meeting
http://www.w3.org/2008/WebVideo/Fragments/wiki/FithF2FAgenda
<conrad> raphael: the agenda is open for suggestions
<conrad> * ACTION-134: Erik to mark up the spec with normative and informative classes [postpone?]
<conrad> * ACTION-139: Silvia to mark up specified sections as implementable
<conrad> raphael: silvia is not here but she has done 138 and 138 (?)
<conrad> close action-138
<trackbot> ACTION-138 Include Erik's diagrams into specification closed
<conrad> close action-139
<trackbot> ACTION-139 Mark up specified sections as implementable closed
Current document: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/
<conrad> raphael: regarding section 5.1.3
<Yves> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-lists
<conrad> raphael: silvia thinks we should also mark it as implementable
<conrad> raphael: the only thing refraining her from that atm is an objection from jack
<conrad> raphael: jack notes that we have not yet concluded if an unspecified dimension should be a zero or not
<conrad> raphael: we need to decide how strict/lax we need to be with interpretations of the spec
<Yves> what happens with http://www.example.com/foo.m4a#t=12-20&this_is_not_a_mediafrag will return a valid mediafrag using 5.1.3
<conrad> jack: i still think that being relaxed is fine, but if something is over-specified, such as specifying two time prefixes or two spatial prefixes, there would be too much scope for error
<conrad> jack: for every cascading rule you can find a use case, where one overrides or extends the other
<conrad> jack: i don't feel confident about stating that one rule can handle 90% of cases
<conrad> jack: if there is no clear rule, eg. saying t=100,200&t=20,40, then how should that be interpreted? there are 3 obvious possible interpretations, and each has people backing it
<conrad> jack: i'm perfectly happy with name=value pairs we don't understand, that is up to implementations
<conrad> jack: if there is a name=value pair that we do understand, we should be stricter about that
<conrad> yves: this is test 3e (?) -- we should be clear about handling of things that are not recognized, partial media fragments etc.
<conrad> yves: a validator should provide errors
<conrad> jack: i agree
<conrad> raphael; for a good combination of things that we can recognize, jack is saying that we shouldn't try to understand what they are doing, but specify a rule
<Yves> things that can be recovered could be close strings, like xyhw -> xywh (obvious typo)
<conrad> jack: yes, according to our spec it should throw an error
<conrad> jack: just like we cannot accept id and t combined should give the same result as two t's combined
<jackjansen> My pref would by: replace all "Any previously set value is discarded" with "it is an error if a value was previously set"
<conrad> silvia: we need to resolve how these ambiguous cases and combined parameters are handled
<conrad> silvia: i think what jack in particular objected to was philip's suggestion that any previous key=value settings are discarded on error
<erik> rssagent, draft minutes
<Yves> +1 to error instead of discarding
<conrad> jack: i would suggest that instead of discarding newly set disallowed values, an error should be thrown
<conrad> jack: from a (parser/UA) implementors point of view, simply discarding seems simpler, but a content author may expect cascading
<Yves> I can think of an intersection of t #t=10,20&t=6,12&intersect
<Yves> not a mediafrag => mediafrag recognition fails
<conrad> jack: i cannot see of a clear rule that prefers discarding or cascading, so we should just specify an error
Jack: we cannot find a general way for cascading rules, so throw an error
<Yves> (defined in another spec, for example)
<conrad> silvia: i agree -- discarding would just encourage lazy programming
<conrad> yves: if there is no specification for an intersection, no problem, but in our case if we don't flag an error then we have to specify it as a valid media fragment
<conrad> yves: i agree that it should be an error
<conrad> conrad: what is an error
<conrad> raphael: it is not a media fragment
<conrad> silvia: it must be simply discarded and the fragment cannot be resolved as a media fragment
<conrad> silvia: [analogy to html page]
<jackjansen> We seem to have moved to 5.1.5
<conrad> raphael: but in the case of an HTML UA, everything is happening within the UA, not on the network
<conrad> silvia: i think it is the same for both html and media resources
<jackjansen> (and I think that that editorial that is attributed to Michael is actually mine:-)
<conrad> silvia: case 1) for html if the # cannot be resolved, the full resource is displayed
yes Jack, but you defer it to Michael a long time ago :-)
<conrad> silvia: for media, if the # cannot be understood, the whole resource is shown from the beginning
<jackjansen> good:-)
<conrad> silvia: case 2) if the resource has previously been loaded: same behaviour, HTML goes to top of page, media should go to the beginning
<conrad> raphael: perhaps we should merge section 5.1.3, 5.1.5 on these topics
<conrad> jack: for error handling, i think we should make sure that put this in informative text not normative text
<conrad> jack: because the best case for handling an error is up to the application
<Yves> also authoring tools should report errors
<conrad> jack: in the case of eg. pay-per-view content the UA may offer to interfere and confirm with the user
<conrad> silvia: i agree
Raphael: there is the proposal of making 5.1.5 into a full section 6
<conrad> silvia: michael, did you get a chance to review the list of error cases presented last week
<mhausenblas> Michael: I agree
<jackjansen> silvia, url?
<mhausenblas> silence == agreement ;)
<conrad> silvia: 5.1.5: we need to look at errors in each of the dimensions (time, track, id)
<conrad> silvia: and then if we look at combined dimensions then we need more cases
<conrad> silvia: hence i'm suggesting to make it into a full section
<scribe> ACTION: Conrad to add a paragraph in the section 5.2.1 that further clarify the role of the UA for rendering a media fragment [recorded in http://www.w3.org/2010/02/17-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-141 - Add a paragraph in the section 5.2.1 that further clarify the role of the UA for rendering a media fragment [on Conrad Parker - due 2010-02-24].
<mhausenblas> hey!
<Zakim> mhausenblas, you wanted to note re appendix
<conrad> michael: i would prefer to have the POV of an implementer that needs/wants to run the test cases
<conrad> michael: from implementer's pov it should be as easy as possible to do their [verification?] work
<scribe> scribenick: Raphael
<scribe> scribenick: raphael
<jackjansen> +1
Suggestion: replace all "Any previously set value is discarded" with "it is an error if a value was previously set" in 5.1.3 and remove editorial note of Jack
<silvia> +1
<mhausenblas> s/Suggegstion/Proposal:
+1
<Yves> +1
<mhausenblas> +1
<conrad> +1
RESOLUTION: replace all "Any previously set value is discarded" with "it is an error if a value was previously set" in 5.1.3 and remove editorial note of Jack
<scribe> ACTION: Troncy to apply this change in the section 5.1.3 (jack's note) [recorded in http://www.w3.org/2010/02/17-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-142 - Apply this change in the section 5.1.3 (jack's note) [on Raphaël Troncy - due 2010-02-24].
Raphael: Providing this change, can we mark this section as implementable?
Jack: adding one more note about id?
Silvia: I would just say that everything concerning the time dimension is implementable, the rest is still under discussion
Jack: I would not move 5.1.5 in an Appendix
Silvia: I would move a section 6 and see later if we move it in an appendix depending the length of the document
<scribe> ACTION: Silvia to move 5.1.5 into a new section [recorded in http://www.w3.org/2010/02/17-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-143 - Move 5.1.5 into a new section [on Silvia Pfeiffer - due 2010-02-24].
Raphael: Section 5.1.1 is related to ISSUE-13
ISSUE-13?
<trackbot> ISSUE-13 -- Write a IETF draft for proposing how to register the fragment scheme for all media types -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13
Silvia: move this section to the top after the introduction
<scribe> ACTION: Silvia to move the section 5.1.1 to the top [recorded in http://www.w3.org/2010/02/17-mediafrag-minutes.html#action04]
<trackbot> Created ACTION-144 - Move the section 5.1.1 to the top [on Silvia Pfeiffer - due 2010-02-24].
Raphael: Section 5.1.4, general
interpretation of media fragments, we have so far a HTML5
browser type of UA in mind
... What are the other UA we are talking about?
Silvia: I'm not sure if we should say that all browsers should render the same way
ACTION-141?
<trackbot> ACTION-141 -- Conrad Parker to add a paragraph in the section 5.2.1 that further clarify the role of the UA for rendering a media fragment -- due 2010-02-24 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/141
Silvia: perhaps start this discussion within the HTML5 fora
<conrad> a non-browser UA could be a video editor as a consumer of media fragments
Jack: maybe we should turn the rendering into a new section as well
Silvia: I like that too
Jack: so we have sections about Syntax, Formal processing and then Guidelines and Errors
Silvia: how far we should go in terms of saying something about rendering of a media fragment is still a matter of discussion
Raphael: other UA ... video editor, qt player, youtube/dailymotion iPhone app, etc.
Silvia: I will start this dicussion thread within the Accessibility task Force of the HTML5 WG
<jackjansen> but also think non-rendering apps (metadata annotation)
Silvia: there are developers there that will udnerstand what we are talking about
Raphael: I'm uncomfortable with
the fact that sections 3, 4.1 and 5.1.1 are marked as
non-normative
... could we just comment that?
Silvia: I tend to ignore that, I rather looked at implementable or not
ACTON-140?
ACTION-140?
<trackbot> ACTION-140 -- Michael Hausenblas to create a more readable version of the TC classification at http://www.w3.org/2008/WebVideo/Fragments/TC/mftc -- due 2010-02-17 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/140
<mhausenblas> http://www.w3.org/2008/WebVideo/Fragments/TC/
Michael: just simple table
layout
... do you have any suggestions?
close ACTION-140
<trackbot> ACTION-140 Create a more readable version of the TC classification at http://www.w3.org/2008/WebVideo/Fragments/TC/mftc closed
Silvia: I have mentionned a list
of errors for the time dimension
... I would appreciate if we could include that into the
TC
... and add them in the Section 6
... it would be good if could agree on that
Michael: I will add these TC in the good place (my action-118) by next week
Raphael: ok, so we discuss that next week
[adjourned]
<mhausenblas> FYI: I've now updated http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCasesOverview
<mhausenblas> so that there is a direct link to the MFTC categorisation and tabular rendering
<mhausenblas> cya
<mhausenblas>