See also: IRC log
<trackbot> Date: 02 November 2010
<scribe> scribe: raphael
<scribe> scribenick: raphael
<foolip> Do we have Zakim set up?
<foolip> Will the France bridge work today?
<davy> scribenick: davy
<foolip> Sorry, I can't hear at all, will try the US bridge instead
raphael: hours in NPT time codes will be optional
<raphael> 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
raphael: SMPTE time codes that do
not match the encoding settings of the media resource result in
an error case
... perhaps 416 is too strong for this case, should we change
this?
<foolip> Zakim: mute me
Yves: send a 200 instead
RESOLUTION: when the server sees a mismatch in requested SMPTE time code and the encoding settings of the media resource, it will return the whole resource (200)
<Yves> => code updated (JavaCC grammar) with optional hours
raphael: comment from Philip:
which pixels should we use (physical pixels or display
pixels)
... we decided to use display pixels
<foolip> CSS is not relevant :)
<foolip> This is not a CSS issue.
<Yves> see http://dev.w3.org/csswg/css3-values/
<Yves> http://dev.w3.org/csswg/css3-values/#the-px-unit
<raphael> Yes Philip, but it is confusing to reuse a term to mean something else that something which has an accepted definition
<raphael> ... so we are right to define what we mean without talking to CSS pixels
<raphael> ... like you said, this has nothing to do with CSS
<foolip> Didn't we already do that yesterday?
<raphael> yes, I'm summarizing the discussion
<raphael> 2nd paragraph of http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
<foolip> No, only the media resource itself has an influence
<raphael> I agree
<dsinger> css pixel latest definitions here <http://fantasai.inkedblade.net/style/specs/css2.1/px-unit>
raphael: other discussion: should
we specify how media fragments are rendered in a browser?
... we created a section 7.1
<Yves> http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0002.html
<foolip> raphael: can you paste links to the mails/bugs you've sent?
<Yves> foolip: see above
Yves: MIME type definition never includes rendering specifications
<foolip> I disagree, I think it's our problem.
<raphael> Dave: presentation should be consistent in all context
<foolip> One might say that the problem is that we have ambiguous syntax, both for t= and xywh=
<foolip> no, ambiguous semantics, rather
<raphael> I'm not sure I see the ambiguity you're talking about
<Yves> the semantic is unambiguous, displaying it is undefined.
<raphael> Jack: I would like that implementers propose both choices (show focus and crop)
<Yves> (undefined, so ambiguous :) )
Dave: so that the choice is up to the author
<pchampin> +1
Jack: if the author decides about the rendering, the rendering should be specified in the URI
Yves: distinction between # and ? is not an option for rendering indications
<raphael> I observe that the room is more and more inclined to add a "crop" keyword
<foolip> I would caution against that, unless you have an implementor willing to implement both xywh and crop.
<raphael> Philip, will you only implement the crop aspect?
<foolip> I know that implementing highlight seems not very useful, but I'm not saying that we *will* implement any other behavior.
<foolip> That's the extent (lack of) commitment :)
<raphael> OK, so your priority 1 will be crop (sprite) ... and of you have resources, highlight, right?
<foolip> No, I don't think there's a reason to ever implement highlighting, and that maaaaybe, given resources, crop could be worthwhile
<raphael> I observe that the group is willing to take an important decision, changing the semantics of rendering spatial media fragments and defaulting to crop
<raphael> Philip will definitively implement "show focus" in context for the temporal dimension, and possibly only "crop" for the spatial dimension
<foolip> Uh, I never said definite about anything.
<raphael> ok Philip :-) I just over interpret what you have said, feel free to correct
<foolip> For #t=10,20 the most useful behavior to implement is focusing, and we *might* implement that, as you saw at FOMS
<foolip> For #xywh=10,10,20,20 the most useful behavior is cropping, but I'm not sure we'd implement even that.
<foolip> It depends on what other browser vendors think, really.
<raphael> thanks for the clarification
<silvia> #xywh with cropping is actually more useful to images than to video
<silvia> e.g. handing over spliced images to a JS API
<silvia> interesting question: what if somebody wants to highlight an area in a cropped frame?
<Yves> you can define a highlight window to be the cropped part
<silvia> #crop=40,40,20,20&xywh=10,10,20,20 would work - but not if we only allowed one
<silvia> Yves, how?
<Yves> img src=foo z-index 0, effect-blur + img src=foo#xywh=.... z-index 1, positionning x,y
<Yves> and you got the higlight
Jack: i would like that there is a CSS styling attribute that indicates if its in or out of focus
<silvia> yeah, but that's not handed on through a URL
<silvia> we don't need any spatial media fragments to do any of this in CSS
<raphael> oups, no I don't understand what you mean?
<silvia> you can do both, cropping and highlighting in HTML with a <video> or <audio> element and CSS, you don't need to provide those coordinates in a URL
<foolip> raphael: thanks
silvia: if we rely on CSS to specify the rendering of spatial fragments, we should rely on CSS for the rendering of all media fragment axes
<Yves> if I read silvia, higlighting is CSS driven, cropping is #xywh=
<foolip> What was the last sentence?
video { temp_frag: highlight; spat_frag: crop )
an example of a CSS statement?
<foolip> Let them use image maps :)
<silvia> from a browser POV we have to make clear statements what happens in a compatible manner across browsers when the URL ends up in the @src attribute of <video> or <img>, and what happens in the URL bar
<dsinger> how about "the normal user-agent behavior is to crop to the indicated spacial and/or temporal region; however note that users and user-agents can easily remove the fragment identifier and view the remainder, and so authors should not rely on the cropping, and user agents may employ other behavior (such as offering users the choice between crop and focus)"
<dsinger> ?
<raphael> Room agrees thay by default, the behavior should be crop
<foolip> Why should we expect them to be consistent, when they're completely different dimensions?
<jackjansen> Because that is called "elegance"
<raphael> scribenick: raphael
Yves: what we need to do is
writing a small IETF document explaining that for video/* the
default behavior is what we are saying in our spec
... correction: what we need to do is not writing nything
... I have discussed with him and we need to write it
<Yves> s/ng
<Yves> > s/Larry/what we need to do/
<foolip> Larry Masinter?
Yves: this document will have to be written when we are in CR stage
ISSUE: Create a IETF draft at CR stage explaining what the media fragment semantics will be for video/*, image/*, audio/*
<trackbot> Created ISSUE-20 - Create a IETF draft at CR stage explaining what the media fragment semantics will be for video/*, image/*, audio/* ; please complete additional details at http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/20/edit .
<foolip> And what about application/ogg then? Seems like a fragile approach.
<foolip> In reality, browsers will apply this in a certain *context* (<video>), not for a certain *MIME type*. It would be nice to not pretend otherwise.
Yves: TAG is discussing with IETF for enforcing them to update their rules for forcing the definition of fragment semantics in mime type
<Yves> foolip, image#xywh might be, CSS for example,
<Yves> to define sprites
<foolip> I'm not sure how that would work, my gut feeling is it's in the wrong layer for it to work out.
Yves: I don't think we will get a review from TAG now
Raphael: who is on the URI
mailing list?
... are you Silvia?
... I want to talk to the mail you forward
Discussing: http://lists.w3.org/Archives/Public/public-media-fragment/2010Oct/0042.html
See also: http://lists.w3.org/Archives/Public/uri/2010Oct/thread.html
The author is very confused
scribe: what is happening depends
on the mime type, not on the scheme
... we trust Silvia to deal with this very well
<jackjansen> +1
We also received comments from the Media Annotations WG
<scribe> ACTION: troncy to address comments from the Media Annotations WG and draft a reply [recorded in http://www.w3.org/2010/11/02-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-196 - Address comments from the Media Annotations WG and draft a reply [on Raphaël Troncy - due 2010-11-09].
<silvia> yes, I am on the URI mailing list
Raphael: I argue that www.youtube.com/watch?v=xx5kBqxyaHE#t=310s should trigger a Range Request
<Yves> if typed in the browser bar, the only way of doing a range request safely would be to use a unit that is compatible with what we expect, so seconds
Silvia: we cannot really enforce anything
<foolip> Incidentally, #t=30 on text/html resources is the most useful, but unfortunately not something we can standardize or implement
<Yves> (as it default to return the whole thing back). Sending byte range requests will add latency and be generally bad in taht case
Silvia: but I will recommend server developers to propagate the info from the video element to the url bar?
<Yves> if we trigger a speciic processing in case of html video, it should be part of html5 then ;)
<foolip> Yes, but I doubt we can overload fragment identifiers for HTML without breaking the web
<silvia> example.com/video.ogv?v=1&t=310s
<Yves> foolip, that was not raphael's point, his point was, what should the browser do before knowing it's html or video
<silvia> example.com/video.html?v=1&t=310s
<Yves> without the context of being in a video element
<silvia> that would signify to the server to change the @src on the first video to an offset with #t=310s
<silvia> ok, we are talking about the situation where the browser doesn't know what type of resource it is getting
Raphael: Silvia,: I'm puzzled we
are still discussing this ... we have discussed since one year
to use the custom units definition of HTTP1.1 for one year, for
exactly this reason
... my argument is, either you are in context (of a video
element), and then, go for recipe 1,
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped
<Yves> using byte ranges in a optimistic there won't help unless we are in the HTML5 <video> case, and if so, the way of using it ought to be defined in html5
Raphael: or you don't know the context (url bar), and then, go for recipe 2, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped
Yves: it depends if browsers want
to implement it
... that will be the case only for the time dimension, and if
UA wants to implement the seconds unit for the
Range
<scribe> ACTION: troncy to also add in the intro of Section 5 a paragraph explaining the optimistic processing of fragments (using ranges in seconds) [recorded in http://www.w3.org/2010/11/02-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-197 - Also add in the intro of Section 5 a paragraph explaining the optimistic processing of fragments (using ranges in seconds) [on Raphaël Troncy - due 2010-11-09].
[coffee break]
<silvia> I didn't bring up this topic, raphael, I do not disagree with anything you said
<silvia> I thought we were discussing my email and the suggestion I had for server apps
Raphael: we are resuming
discussions and we need to be efficient
... we will discuss and resolve extensibility issue in 45 min
max
... and then vote on the cropping issue for spatial media
fragment
Philip, Silvia, please, be on this channel in 45 min for voting
ACTION-181?
<trackbot> ACTION-181 -- Jack Jansen to investigate how escaping is defined in uri spec -- due 2010-07-07 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/181
Jack: the URI spec does not say anything about further sub-division between delims and sub-delims
See: http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0000.html
Jack: if we first parse between
& and =, and then do %-decode, we do the right thing
... but we need to write down that %-decode must happen after
the splitting
close ACTION-181
<trackbot> ACTION-181 Investigate how escaping is defined in uri spec closed
Section 4.1: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#general-structure
<Yves> %-decoding of non-(delims/sub-delims) may happen anytime, so we consider it is done for the sake of readability of the grammar
Raphael: I suggest to add this sentence in the specification
close ACTION-185
<trackbot> ACTION-185 Book zakim for the 2 days meeting of the group on Mon 1st and Tue 2nd Nov closed
ACTION-189
ACTION-189?
<trackbot> ACTION-189 -- Raphaël Troncy to put the top-level production rules back into the document (in section 4.3.5 or 4.1) -- due 2010-10-06 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189
Old proposal was
mediasegment = namesegment / axissegment
axissegment = ( timesegment / spacesegment / tracksegment ) *( "&" ( timesegment / spacesegment / tracksegment )
<scribe> New proposal is:
mediasegment = namesegment / axissegment / extensionsegment
extensionsegment = extensionprefix '=' extensionparam
+ prose to state that a media segment cannot be only an extension segment
<Yves> + warning to say that it should not conflict with an existing axis
extensionprefix and extensionsegment are like the values (pchar - the subdelims)
Proposal: vote for changing the top level production rules into this proposal
<jackjansen> +0
Raphael: I invite everybody to vote
<Yves> -0
<davy> +1
+1
Provisory results: 2 for, 2 abstain, 0 against
scribe: I will wait for the votes of Silvia and Philip before resolving
Jack: next issue, how do we treat values and units that we don't understand in dimensions of media fragments?
Raphael: should we allow
this?
... example: #t=morning ? #t=wallclock:10,25 ?
Jack: I think we should not have them (both)
Davy: I agree with Jack
Yves: if we get extensibility on other axis, then I think we should have extensibility for units and values we don't know, for consistency
<jackjansen> I agree with Yves on the consistency argument, but here practicality beats purity.
Raphael: I agree with Jack and Davy, we should be limited to the units and values we can parse and not allow the rest
<jackjansen> I would really not like the extensibility but accept it for practical reasons (hence +0). This is a bridge too far, however.
Proposal: vote +1 if you want to modify the grammar in order to allow extensibility on units and values we don't currently understand, and -1 if you don't want such a grammar change
<jackjansen> -1
-1
<davy> -1
<Yves> ~0
Provisory results: 3 against changing the grammar, 1 abstain
scribe: I will wait for the votes of Silvia and Philip before resolving
<foolip> ok, it's going to end at 12
<foolip> can you wait?
Yes
<foolip> thanks
<foolip> uh, it was apparently 12:15
<foolip> anyway, I'll type what I think right now
<foolip> I think "extensibility" is not really the issue, and I don't think we need to change the grammar for this reason
<foolip> However, the processing should tolerate (by ignoring) #t=morning or #t=wallclock:10,25
<foolip> That has nothing to do with syntax or validity.
<foolip> So for the extensionsegment syntax change, I would vote again, as it doesn't fix ISSUE-19
<foolip> ISSUE-19 requires more sweeping changes to the spec
Philip, we will wait for 12:15 you're back, don't worry
thanks for your comment, and by "again", I guess you meant "against" ?
<foolip> yes
furthermore, everybody agrees that #t=morning or #t=wallclock:10,25 should be ignored (good point)
scribe: these are not and will never be media fragments 1.0
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: there is nothing in the
grammar that says where %-decoding and utf-8 decoding
happen
... perhaps the %-decoding is specified in the uri spec
<Yves> %-decoding is indeed defined in rfc3986 (especially for non delims/sub-delims)
Philip, it is written in 4.2
A specification of the parsing algorithm to extract these from an actual URI can be found in D.1 Processing name-value components and D.2 Processing name-value lists. Note that the URI works on octet strings, but the parsed name-value pairs are unicode strings, since percent-encoding is resolved. Percent-decoding of non-(delims/sub-delims) may happen anytime, so we consider it is done for the sake of readability of the grammar. The following definitions
Philip: let's go back to ISSUE-19
<silvia> I agree with issue-19
<silvia> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19
<silvia> I think the proposed changes are trying to realize the requirements that you wrote in issue-19
yes silvia
<silvia> Old proposal was
<silvia> mediasegment = namesegment / axissegment
<silvia> axissegment = ( timesegment / spacesegment / tracksegment ) *( "&" ( timesegment / spacesegment / tracksegment )
<silvia> New proposal is:
<silvia> mediasegment = namesegment / axissegment / extensionsegment
<silvia> extensionsegment = extensionprefix '=' extensionparam
thanks silvia
A specification of the parsing algorithm to extract these from an actual URI can be found in D.1 Processing name-value components and D.2 Processing name-value lists. Note that the URI works on octet strings, but the parsed name-value pairs are unicode strings, since percent-encoding is resolved. Percent-decoding of non-(delims/sub-delims) may happen anytime, so we consider it is done for the sake of readability of the grammar. The following definitions
From the section 4.2, last paragraph, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#url-serialization
<silvia> I tend to agree with Jack
<Yves> I thought that we were happy to have the grammar+text, and other people would work on an algorithm
Raphael: the ISSUE-19 mentions 3
things
... be rigid on the grammar to flag errors for validator ...
this is what the grammar is used for
... allow graceful extensibility ... this is dealt with the
proposal change in the production rules
... match what most scripting languages do currently ... no
evidence that what we have made go agains this
... so I don't see why ISSUE-19 is not resolved
<raphael> New proposal is:
<raphael> mediasegment = namesegment / axissegment / extensionsegment
<raphael> extensionsegment = extensionprefix '=' extensionparam
<raphael> + prose to state that a media segment cannot be only an extension segment
<Yves> + warning to say that it should not conflict with an existing axis
ACTIOn-189?
<trackbot> ACTION-189 -- Raphaël Troncy to put the top-level production rules back into the document (in section 4.3.5 or 4.1) -- due 2010-10-06 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189
<raphael> Proposal: vote for changing the top level production rules into this proposal
<jackjansen> +0
<raphael> Raphael: I invite everybody to vote
<Yves> -0
<davy> +1
<raphael> +1
<raphael> Provisory results: 2 for, 2 abstain, 0 against
<raphael> ... I will wait for the votes of Silvia and Philip before resolving
<silvia> +1
<foolip> -1
<silvia> what are you missing?
Philip: it is not clear that utf-8 decoding happen on both names and values
Yves: all the values and names
that are not explicitly said utf-8 strings are ASCII so utf-8
compatible
... we might need to add this for extensionprefix and
extensionparam
<silvia> yes, I think it needs to be added to extensionsprefix and extensionparam - though it could be noted generally
Jack: I would like to have the 2 votes and adjourned
Proposal: vote for changing the top level production rules and include the extensionsegment for enabling extensibility
<jackjansen> -
<jackjansen> -1
<foolip> -1
<davy> -1
<Yves> ~0
+1
<silvia> can we come up with a meta production rule on fragments, something like mediafragment = [name = value]*
<silvia> and then associate it to that?
<silvia> -1
RESOLUTION: no extensionsegment to be added in the spec
close ACTION-189
<trackbot> ACTION-189 Put the top-level production rules back into the document (in section 4.3.5 or 4.1) closed
<silvia> we need to improve that part of the spec
Results: 4 against, 1 for, 1 abstain
<silvia> rejecting the solution doesn't mean that the topic is solved
Proposal: vote +1 if you want to modify the grammar in order to allow extensibility on units and values we don't currently understand, and -1 if you don't want such a grammar change
<foolip> -1
<silvia> +1
<silvia> -1
Results: 5 against, 1 abstain
<silvia> sorry :)
RESOLUTION: we just ignore values and units we do not understand
Proposal: vote +1 of you want the default behavior of #xywh=10,10,10,10 be cropping when rendered and -1 if you don't want
<foolip> +1
<silvia> +1
<davy> +1
<jackjansen> +1
0
<Yves> =0
4 for, 2 abstain
Proposal: vote +1 of you want the only behavior of #xywh=10,10,10,10 be cropping when rendered and -1 if you don't want
<jackjansen> -1
<Yves> +1
<davy> -1
<silvia> +1
<foolip> +1
+1
RESOLUTION: The default and only behavior of #xywh=10,10,10,10 is cropping when rendered
<silvia> you miss the important part in that resolution: "when rendered"
<scribe> ACTION: troncy to edit section 7.1 for taking into account the cropping resolution [recorded in http://www.w3.org/2010/11/02-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-198 - Edit section 7.1 for taking into account the cropping resolution [on Raphaël Troncy - due 2010-11-09].
<foolip> My suggestion for ISSUE-19 is still <http://lists.w3.org/Archives/Public/public-media-fragment/2010Aug/0005.html> and what would necessarily follow.
<silvia> foolip, that is the meta rule I tried to suggest above
<silvia> Yves, do you think the production rule can be changed accordingly?
<foolip> silvia, indeed
Yves thinks that this resolve nothing
<silvia> you can then make name and value utf8string
<Yves> 'npt' is ascii so utf8, saying that it's just an utf-8 encoded string doesn't add anything, it in fact removes that fact that it's 'npt'
<foolip> Of course it's not the whole solution, it's step 1.
<silvia> yeah, you continue with what is there, just as a type of namevalue
<Yves> the algorithm should say that 1/ cut at &, then name=value, 3/ it's utf-8, 4/ if npt do this...
<Yves> but that is orthogonal to having the grammar saying what are the valid values
<foolip> With this grammar, there's no need for the first algorithm in section D.
<silvia> I guess we have two diverging views here: the grammar is a production rule and the algo in section D is a dissecting approach
<foolip> I heard.
<foolip> But, I think it would be more fruitful to actually see what the alternative is.
Raphael: I will talk with Erik offline, and push for the status quo as the spec is written today and go with the risk of having a formal objection at some point
<Yves> foolip we can't have grammar = "name = value" , then "name = 'npt' | 'track'" and values ' npttime | utf8string' , so the grammar can't start with a generic name = value
<Yves> however, a parsing algorithm might perfectly well say that
<Yves> those are different things
<foolip> Yves, of course, the grammars for each dimension operate on the *result* of splitting name-value pairs, it's not in one layer of syntax.
<Yves> the grammar can operate on the splitting of '&' as otherwise <nptname> = <trackvalue> would be ok
[meeting adjourned]
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/: hould/: should/ Succeeded: s/smantic/semantic/ Succeeded: s/exactly Sylvia!/oups, no I don't understand what you mean?/ Succeeded: s/Larry/what we need to do/ Succeeded: s/Larry/what we need to do/g WARNING: Bad s/// command: s/ng Succeeded: s/Silvia/Raphael: Silvia,/ Succeeded: s/first decode/first parse/ Succeeded: s/extensioprefix/extensionprefix/ Succeeded: s/whay/why/ Succeeded: s/RESOLUTION: The default and only behavior of #xywh=10,10,10,10 is cropping/RESOLUTION: The default and only behavior of #xywh=10,10,10,10 is cropping when rendered/ Found Scribe: raphael Inferring ScribeNick: raphael Found ScribeNick: raphael Found ScribeNick: davy Found ScribeNick: raphael ScribeNicks: raphael, davy WARNING: Dash separator lines found. If you intended them to mark the start of a new topic, you need the -dashTopics option. For example: <Philippe> --- <Philippe> Review of Action Items Present: Davy Raphael Dave_Singer Yves Jack Silvia Philip Found Date: 02 Nov 2010 Guessing minutes URL: http://www.w3.org/2010/11/02-mediafrag-minutes.html People with action items: troncy[End of scribe.perl diagnostic output]