07:40:44 <RRSAgent> RRSAgent has joined #mediafrag
07:40:44 <RRSAgent> logging to http://www.w3.org/2010/11/02-mediafrag-irc
07:40:46 <trackbot> RRSAgent, make logs public
07:40:46 <Zakim> Zakim has joined #mediafrag
07:40:48 <trackbot> Zakim, this will be IA_MFWG
07:40:48 <Zakim> ok, trackbot; I see IA_MFWG(TPAC)3:00AM scheduled to start 40 minutes ago
07:40:49 <trackbot> Meeting: Media Fragments Working Group Teleconference
07:40:49 <trackbot> Date: 02 November 2010
07:41:07 <raphael> Chair: Raphael
07:41:53 <raphael> Present: Davy, Raphael, Dave Singer, Yves, Jack, Silvia, Philip
07:42:04 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
07:55:30 <raphael> scribe: raphael
07:55:36 <raphael> scribenick: raphael
07:57:05 <homata> homata has joined #mediafrag
07:57:17 <hidetaka> hidetaka has joined #mediafrag
07:57:19 <raphael> Topic: 1. Action Points review
07:58:34 <foolip> Do we have Zakim set up?
08:05:02 <jackjansen> jackjansen has joined #mediafrag
08:07:42 <Nobu> Nobu has joined #mediafrag
08:14:45 <foolip_> foolip_ has joined #mediafrag
08:14:58 <raphael> zakim, dial Roseraie_1
08:14:58 <Zakim> ok, raphael; the call is being made
08:14:59 <Zakim> IA_MFWG(TPAC)3:00AM has now started
08:15:00 <Zakim> +Roseraie_1
08:16:10 <Franck> Franck has joined #mediafrag
08:17:07 <foolip> Will the France bridge work today?
08:18:34 <davy> scribenick: davy
08:18:43 <Zakim> + +46.3.13.48.aaaa
08:19:05 <davy> Topic: summarizing yesterday's achievements
08:19:09 <foolip> Sorry, I can't hear at all, will try the US bridge instead
08:19:49 <sgondo> sgondo has joined #mediafrag
08:19:52 <Zakim> - +46.3.13.48.aaaa
08:19:55 <davy> raphael: hours in NPT time codes will be optional
08:20:11 <raphael> ACTIOn-192?
08:20:11 <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
08:20:11 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/192
08:20:35 <davy> ... SMPTE time codes that do not match the encoding settings of the media resource result in an error case
08:20:52 <Zakim> + +46.3.13.48.aabb
08:21:12 <davy> ... perhaps 416 is too strong for this case, should we change this?
08:21:28 <foolip> Zakim: mute me
08:22:55 <davy> Yves: send a 200 instead
08:23:53 <davy> 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)
08:24:26 <Yves> => code updated (JavaCC grammar) with optional hours
08:24:52 <davy> raphael: comment from Philip: which pixels should we use (physical pixels or display pixels)
08:25:11 <davy> ... we decided to use display pixels 
08:25:51 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html davy
08:28:44 <foolip> CSS is not relevant :)
08:28:58 <foolip> This is not a CSS issue.
08:29:27 <Yves> see http://dev.w3.org/csswg/css3-values/
08:29:37 <Yves> http://dev.w3.org/csswg/css3-values/#the-px-unit
08:30:29 <raphael> Yes Philip, but it is confusing to reuse a term to mean something else that something which has an accepted definition
08:30:44 <raphael> ... so we are right to define what we mean without talking to CSS pixels
08:30:58 <raphael> ... like you said, this has nothing to do with CSS
08:30:59 <foolip> Didn't we already do that yesterday?
08:31:09 <raphael> yes, I'm summarizing the discussion
08:31:50 <raphael> 2nd paragraph of http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space
08:34:55 <foolip> No, only the media resource itself has an influence
08:35:44 <raphael> I agree
08:35:51 <dsinger> dsinger has joined #mediafrag
08:36:25 <dsinger> css pixel latest definitions here <http://fantasai.inkedblade.net/style/specs/css2.1/px-unit>
08:39:25 <davy> raphael: other discussion: hould we specify how media fragments are rendered in a browser?
08:39:54 <davy> ... we created a section 7.1 
08:39:57 <Yves> http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0002.html
08:40:03 <foolip> raphael: can you paste links to the mails/bugs you've sent?
08:40:12 <davy> s/: hould/: should
08:40:21 <Yves> foolip: see above
08:42:31 <davy> Yves: MIME type definition never includes rendering specifications
08:45:39 <foolip> I disagree, I think it's our problem.
08:47:15 <raphael> Dave: presentation should be consistent in all context
08:47:36 <foolip> One might say that the problem is that we have ambiguous syntax, both for t= and xywh=
08:47:51 <foolip> no, ambiguous semantics, rather
08:48:07 <raphael> I'm not sure I see the ambiguity you're talking about
08:48:18 <Yves> the smantic is unambiguous, displaying it is undefined.
08:48:24 <raphael> Jack: I would like that implementers propose both choices (show focus and crop)
08:48:37 <raphael> s/smantic/semantic
08:48:39 <Yves> (undefined, so ambiguous :) )
08:48:59 <davy> Dave: so that the choice is up to the author
08:49:08 <pchampin> +1
08:51:12 <davy> Jack: if the author decides about the rendering, the rendering should be specified in the URI
08:51:29 <davy> Yves: distinction between # and ? is not an option for rendering indications
08:51:41 <raphael> I observe that the room is more and more inclined to add a "crop" keyword
08:52:15 <foolip> I would caution against that, unless you have an implementor willing to implement both xywh and crop.
08:52:50 <raphael> Philip, will you only implement the crop aspect?
08:53:26 <foolip> I know that implementing highlight seems not very useful, but I'm not saying that we *will* implement any other behavior.
08:53:40 <foolip> That's the extent (lack of) commitment :)
08:54:18 <raphael> OK, so your priority 1 will be crop (sprite) ... and of you have resources, highlight, right?
08:55:09 <foolip> No, I don't think there's a reason to ever implement highlighting, and that maaaaybe, given resources, crop could be worthwhile
08:59:31 <Zakim> +silvia
08:59:37 <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
09:00:19 <raphael> Philip will definitively implement "show focus" in context for the temporal dimension, and possibly only "crop" for the spatial dimension
09:01:05 <foolip> Uh, I never said definite about anything.
09:01:27 <raphael> ok Philip :-) I just over interpret what you have said, feel free to correct
09:01:52 <foolip> For #t=10,20 the most useful behavior to implement is focusing, and we *might* implement that, as you saw at FOMS
09:02:21 <foolip> For #xywh=10,10,20,20 the most useful behavior is cropping, but I'm not sure we'd implement even that.
09:02:35 <foolip> It depends on what other browser vendors think, really.
09:02:51 <raphael> thanks for the clarification
09:03:25 <silvia> #xywh with cropping is actually more useful to images than to video
09:04:13 <silvia> e.g. handing over spliced images to a JS API
09:05:48 <silvia> zakim, mute me
09:05:48 <Zakim> silvia should now be muted
09:09:09 <silvia> interesting question: what if somebody wants to highlight an area in a cropped frame?
09:09:27 <Yves> you can define a highlight window to be the cropped part
09:09:50 <silvia> #crop=40,40,20,20&xywh=10,10,20,20 would work - but not if we only allowed one
09:10:17 <silvia> Yves, how?
09:11:00 <Yves> img src=foo z-index 0, effect-blur + img src=foo#xywh=.... z-index 1, positionning x,y
09:11:05 <Yves> and you got the higlight
09:11:26 <davy> Jack: i would like that there is a CSS styling attribute that indicates if its in or out of focus
09:11:31 <silvia> yeah, but that's not handed on through a URL
09:11:49 <silvia> we don't need any spatial media fragments to do any of this in CSS
09:11:58 <raphael> exactly Sylvia!
09:12:24 <raphael> s/exactly Sylvia!/oups, no I don't understand what you mean?
09:13:05 <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
09:13:55 <silvia> zakim, unmute me
09:13:55 <Zakim> silvia should no longer be muted
09:14:31 <foolip> zakim, mute me
09:14:31 <Zakim> sorry, foolip, I do not know which phone connection belongs to you
09:15:04 <raphael> zakim, aabbb is foolip
09:15:04 <Zakim> sorry, raphael, I do not recognize a party named 'aabbb'
09:15:08 <raphael> zakim, aabb is foolip
09:15:08 <Zakim> +foolip; got it
09:15:13 <foolip> zakim, mute me
09:15:13 <Zakim> foolip should now be muted
09:15:18 <foolip> raphael: thanks
09:15:19 <davy> 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
09:15:36 <Yves> if I read silvia, higlighting is CSS driven, cropping is #xywh=
09:15:55 <foolip> What was the last sentence?
09:17:03 <davy> video { temp_frag: highlight; spat_frag: crop )
09:17:19 <davy> an example of a CSS statement?
09:19:38 <foolip> Let them use image maps :)
09:25:04 <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
09:25:06 <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)"
09:25:08 <dsinger> ?
09:25:08 <raphael> Room agrees thay by default, the behavior should be crop
09:25:40 <silvia> zakim, mute me
09:25:40 <Zakim> silvia should now be muted
09:26:28 <foolip> Why should we expect them to be consistent, when they're completely different dimensions?
09:26:49 <jackjansen> Because that is called "elegance"
09:27:10 <raphael> scribenick: raphael
09:27:18 <raphael> Topic: 2. IETF and TAG updates
09:27:55 <sgondo> sgondo has joined #mediafrag
09:28:07 <raphael> Yves: Larry is writing a small IETF document explaining that for video/* the default behavior is what we are saying in our spec
09:28:39 <raphael> ... correction: Larry is not writing nything
09:28:41 <Yves> s/Larry/what we need to do/
09:28:46 <Yves> s/Larry/what we need to do/g
09:28:57 <raphael> ... I have discussed with him and we need to write it
09:28:57 <Yves> s/ng
09:28:57 <Yves> > s/Larry/what we need to do/
09:29:03 <foolip> Larry Masinter?
09:29:10 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
09:29:29 <raphael> Yves: this document will have to be written when we are in CR stage
09:30:19 <raphael> ISSUE: Create a IETF draft at CR stage explaining what the media fragment semantics will be for video/*, image/*, audio/*
09:30:19 <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 .
09:30:25 <foolip> And what about application/ogg then? Seems like a fragile approach.
09:31:19 <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.
09:31:42 <raphael> Yves: TAG is discussing with IETF for enforcing them to update their rules for forcing the definition of fragment semantics in mime type
09:32:03 <Yves> foolip, image#xywh might be, CSS for example, 
09:32:12 <Yves> to define sprites
09:32:53 <foolip> I'm not sure how that would work, my gut feeling is it's in the wrong layer for it to work out.
09:33:38 <raphael> Yves: I don't think we will get a review from TAG now
09:33:56 <raphael> Topic: 3. Comments on the spec
09:34:30 <raphael> Raphael: who is on the URI mailing list?
09:34:39 <raphael> ... are you Silvia?
09:34:54 <raphael> ... I want to talk to the mail you forward
09:35:44 <raphael> Discussing: http://lists.w3.org/Archives/Public/public-media-fragment/2010Oct/0042.html
09:36:53 <raphael> See also: http://lists.w3.org/Archives/Public/uri/2010Oct/thread.html
09:39:16 <raphael> The author is very confused
09:39:45 <raphael> ... what is happening depends on the mime type, not on the scheme
09:40:08 <raphael> ... we trust Silvia to deal with this very well
09:40:11 <jackjansen> +1
09:42:13 <raphael> We also received comments from the Media Annotations WG
09:42:57 <raphael> ACTION: troncy to address comments from the Media Annotations WG and draft a reply
09:42:57 <trackbot> Created ACTION-196 - Address comments from the Media Annotations WG and draft a reply [on Raphaël Troncy - due 2010-11-09].
09:44:13 <silvia> yes, I am on the URI mailing list
09:47:05 <raphael> Topic: 4. Use of a media fragment URI in a browser bar
09:47:25 <foolip> zakim, unmute me
09:47:25 <Zakim> foolip should no longer be muted
09:47:35 <raphael> Raphael: I argue that www.youtube.com/watch?v=xx5kBqxyaHE#t=310s should trigger a Range Request
09:48:08 <silvia> zakim, unmute me
09:48:08 <Zakim> silvia should no longer be muted
09:49:09 <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
09:49:46 <foolip> zakim, mute me
09:49:46 <Zakim> foolip should now be muted
09:50:12 <raphael> Silvia: we cannot really enforce anything
09:50:12 <foolip> Incidentally, #t=30 on text/html resources is the most useful, but unfortunately not something we can standardize or implement
09:50:13 <Yves> (as it default to return the whole thing back). Sending byte range requests will add latency and be generally bad in taht case
09:51:23 <raphael> ... but I will recommend server developers to propagate the info from the video element to the url bar?
09:52:00 <Yves> if we trigger a speciic processing in case of html video, it should be part of html5 then ;)
09:52:51 <foolip> Yes, but I doubt we can overload fragment identifiers for HTML without breaking the web
09:52:52 <silvia> example.com/video.ogv?v=1&t=310s
09:53:20 <Yves> foolip, that was not raphael's point, his point was, what should the browser do before knowing it's html or video
09:53:22 <silvia> example.com/video.html?v=1&t=310s
09:53:43 <Yves> without the context of being in a video element
09:53:43 <silvia> that would signify to the server to change the @src on the first video to an offset with #t=310s
09:56:22 <silvia> ok, we are talking about the situation where the browser doesn't know what type of resource it is getting
09:56:29 <silvia> zakim, mute me
09:56:29 <Zakim> silvia should now be muted
09:57:43 <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
09:57:53 <raphael> s/Silvia/Raphael: Silvia,
09:58:58 <Zakim> -silvia
09:59:00 <raphael> Raphael: 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
09:59:42 <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
10:00:25 <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
10:01:20 <raphael> Yves: it depends if browsers want to implement it
10:01:49 <raphael> ... that will be the case only for the time dimension, and if UA wants to implement the seconds unit for the Range
10:04:05 <raphael> ACTION: troncy to also add in the intro of Section 5 a paragraph explaining the optimistic processing of fragments (using ranges in seconds)
10:04:05 <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].
10:04:14 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
10:04:18 <raphael> [coffee break]
10:05:11 <silvia> I didn't bring up this topic, raphael, I do not disagree with anything you said
10:05:38 <silvia> I thought we were discussing my email and the suggestion I had for server apps
10:08:39 <homata> homata has joined #mediafrag
10:09:28 <hidetaka> hidetaka has joined #mediafrag
10:23:42 <jackjansen> jackjansen has joined #mediafrag
10:24:20 <pchampin> pchampin has joined #mediafrag
10:24:32 <raphael> Raphael: we are resuming discussions and we need to be efficient
10:24:48 <raphael> ... we will discuss and resolve extensibility issue in 45 min max
10:25:01 <raphael> ... and then vote on the cropping issue for spatial media fragment
10:25:18 <dsinger> dsinger has joined #mediafrag
10:25:26 <raphael> Philip, Silvia, please, be on this channel in 45 min for voting
10:25:48 <raphael> Topic: 5. Extensibility
10:26:23 <raphael> ACTION-181?
10:26:23 <trackbot> ACTION-181 -- Jack Jansen to investigate how escaping is defined in uri spec -- due 2010-07-07 -- OPEN
10:26:23 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/181
10:27:02 <raphael> Jack: the URI spec does not say anything about further sub-division between delims and sub-delims
10:27:31 <raphael> See: http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0000.html
10:28:06 <raphael> Jack: if we first decode between & and =, and then do %-decode, we do the right thing
10:28:25 <raphael> ... but we need to write down that %-decode must happen after the splitting
10:29:36 <raphael> close ACTION-181
10:29:36 <trackbot> ACTION-181 Investigate how escaping is defined in uri spec closed
10:29:42 <jackjansen> s/first decode/first parse
10:29:58 <raphael> Section 4.1: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#general-structure
10:30:12 <Yves> %-decoding of non-(delims/sub-delims) may happen anytime, so we consider it is done for the sake of readability of the grammar
10:31:25 <raphael> Raphael: I suggest to add this sentence in the specification
10:31:47 <raphael> close ACTION-185
10:31:47 <trackbot> ACTION-185 Book zakim for the 2 days meeting of the group on Mon 1st and Tue 2nd Nov closed
10:32:56 <raphael> ACTION-189
10:32:58 <raphael> ACTION-189?
10:32:58 <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
10:32:58 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189
10:34:21 <raphael> Old proposal was
10:34:22 <raphael> mediasegment = namesegment / axissegment
10:34:42 <raphael> axissegment = ( timesegment / spacesegment / tracksegment ) *( "&" ( timesegment / spacesegment / tracksegment )
10:34:54 <raphael> New proposal is:
10:34:55 <raphael> mediasegment = namesegment / axissegment / extensionsegment
10:35:04 <raphael> extensionsegment = extensionprefix '=' extensionparam
10:35:21 <raphael> + prose to state that a media segment cannot be only an extension segment
10:36:07 <Yves> + warning to say that it should not conflict with an existing axis
10:36:14 <youenn> youenn has joined #mediafrag
10:37:45 <raphael> extensioprefix and extensionsegment are like the values (pchar - the subdelims)
10:38:36 <Franck> s/extensioprefix/extensionprefix
10:38:51 <raphael> Proposal: vote for changing the top level production rules into this proposal
10:39:04 <jackjansen> +0
10:39:11 <raphael> Raphael: I invite everybody to vote
10:39:14 <Yves> -0
10:39:34 <davy> +1
10:39:50 <raphael> +1
10:40:39 <raphael> Provisory results: 2 for, 2 abstain, 0 against
10:40:54 <raphael> ... I will wait for the votes of Silvia and Philip before resolving
10:42:14 <raphael> Jack: next issue, how do we treat values and units that we don't understand in dimensions of media fragments?
10:42:37 <raphael> Raphael: should we allow this?
10:43:33 <raphael> ... example: #t=morning ? #t=wallclock:10,25 ?
10:43:50 <raphael> Jack: I think we should not have them (both)
10:44:05 <raphael> Davy: I agree with Jack
10:45:01 <raphael> 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
10:45:35 <jackjansen> I agree with Yves on the consistency argument, but here practicality beats purity.
10:45:44 <raphael> Raphael: I agree with Jack and Davy, we should be limited to the units and values we can parse and not allow the rest
10:46:00 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
10:46:16 <jackjansen> I would really not like the extensibility but accept it for practical reasons (hence +0). This is a bridge too far, however.
10:50:37 <raphael> 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 
10:50:44 <jackjansen> -1
10:50:47 <raphael> -1
10:50:49 <davy> -1
10:51:08 <Yves> ~0
10:51:34 <raphael> Provisory results: 3 against changing the grammar, 1 abstain
10:51:40 <raphael> ...  I will wait for the votes of Silvia and Philip before resolving
10:55:40 <foolip> ok, it's going to end at 12
10:56:11 <foolip> can you wait?
10:57:17 <raphael> Yes
10:57:32 <foolip> thanks
11:00:56 <foolip> uh, it was apparently 12:15
11:01:12 <foolip> anyway, I'll type what I think right now
11:01:41 <foolip> I think "extensibility" is not really the issue, and I don't think we need to change the grammar for this reason
11:02:15 <foolip> However, the processing should tolerate (by ignoring) #t=morning or #t=wallclock:10,25
11:02:32 <foolip> That has nothing to do with syntax or validity.
11:03:24 <foolip> So for the extensionsegment syntax change, I would vote again, as it doesn't fix ISSUE-19
11:03:48 <sgondo> sgondo has joined #mediafrag
11:04:17 <foolip> ISSUE-19 requires more sweeping changes to the spec
11:05:31 <raphael> Philip, we will wait for 12:15 you're back, don't worry
11:05:47 <raphael> thanks for your comment, and by "again", I guess you meant "against" ?
11:06:11 <foolip> yes
11:06:19 <raphael> furthermore, everybody agrees that #t=morning or #t=wallclock:10,25 should be ignored (good point)
11:06:34 <raphael> ... these are not and will never be media fragments 1.0
11:09:55 <Zakim> +foolip.a
11:10:33 <raphael> ISSUE-19?
11:10:33 <trackbot> ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open
11:10:33 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19
11:10:35 <Zakim> +silvia
11:10:38 <silvia> zakim, mute me
11:10:38 <Zakim> silvia should now be muted
11:14:19 <raphael> Philip: there is nothing in the grammar that says where %-decoding and utf-8 decoding happen
11:14:31 <raphael> ... perhaps the %-decoding is specified in the uri spec
11:15:00 <Yves> %-decoding is indeed defined in rfc3986 (especially for non delims/sub-delims)
11:16:08 <raphael> Philip, it is written in 4.2
11:16:09 <raphael> 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 
11:19:20 <raphael> Philip: let's go back to ISSUE-19
11:19:22 <Franck> Franck has joined #mediafrag
11:20:10 <silvia> I agree with issue-19
11:20:34 <silvia> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19
11:21:10 <silvia> I think the proposed changes are trying to realize the requirements that you wrote in issue-19
11:21:49 <raphael> yes silvia
11:22:29 <silvia> Old proposal was
11:22:29 <silvia> mediasegment = namesegment / axissegment
11:22:29 <silvia> axissegment = ( timesegment / spacesegment / tracksegment ) *( "&" ( timesegment / spacesegment / tracksegment )
11:22:29 <silvia> New proposal is:
11:22:29 <silvia> mediasegment = namesegment / axissegment / extensionsegment
11:22:30 <silvia> extensionsegment = extensionprefix '=' extensionparam
11:23:28 <raphael> thanks silvia
11:23:50 <raphael> 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 
11:24:11 <raphael> From the section 4.2, last paragraph, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#url-serialization
11:24:52 <silvia> I tend to agree with Jack
11:25:38 <Yves> I thought that we were happy to have the grammar+text, and other people would work on an algorithm
11:29:04 <raphael> Raphael: the ISSUE-19 mentions 3 things
11:29:25 <raphael> ... be rigid on the grammar to flag errors for validator ... this is what the grammar is used for
11:29:44 <raphael> ... allow graceful extensibility ... this is dealt with the proposal change in the production rules
11:30:14 <raphael> ... match what most scripting languages do currently ... no evidence that what we have made go agains this
11:30:28 <raphael> ... so I don't see whay ISSUE-19 is not resolved
11:31:03 <raphael> s/whay/why
11:32:49 <raphael> <raphael> New proposal is:
11:32:49 <raphael> <raphael> mediasegment = namesegment / axissegment / extensionsegment
11:32:49 <raphael> <raphael> extensionsegment = extensionprefix '=' extensionparam
11:32:49 <raphael> <raphael> + prose to state that a media segment cannot be only an extension segment
11:32:49 <raphael> <Yves> + warning to say that it should not conflict with an existing axis
11:33:41 <raphael> ACTIOn-189?
11:33:41 <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
11:33:41 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189
11:34:54 <raphael> <raphael> Proposal: vote for changing the top level production rules into this proposal
11:34:54 <raphael> <jackjansen> +0
11:34:54 <raphael> <raphael> Raphael: I invite everybody to vote
11:34:54 <raphael> <Yves> -0
11:34:54 <raphael> <davy> +1
11:34:55 <raphael> <raphael> +1
11:34:57 <raphael> <raphael> Provisory results: 2 for, 2 abstain, 0 against
11:34:59 <raphael> <raphael> ... I will wait for the votes of Silvia and Philip before resolving
11:35:16 <silvia> +1
11:35:49 <foolip> foolip has joined #mediafrag
11:36:29 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html Yves
11:36:48 <foolip> -1
11:37:17 <silvia> what are you missing?
11:37:48 <raphael> Philip: it is not clear that utf-8 decoding happen on both names and values
11:39:10 <raphael> Yves: all the values and names that are not explicitly said utf-8 strings are ASCII so utf-8 compatible
11:39:34 <raphael> ... we might need to add this for extensionprefix and extensionparam
11:40:41 <jackjansen> q+
11:41:03 <raphael> zakim, ack jackjansen
11:41:03 <Zakim> I see no one on the speaker queue
11:41:13 <silvia> yes, I think it needs to be added to extensionsprefix and extensionparam - though it could be noted generally
11:41:14 <raphael> Jack: I would like to have the 2 votes and adjourned
11:42:05 <raphael> Proposal: vote for changing the top level production rules and include the extensionsegment for enabling extensibility
11:42:10 <jackjansen> -
11:42:13 <jackjansen> -1
11:42:20 <foolip> -1
11:42:21 <davy> -1
11:42:26 <Yves> ~0
11:42:28 <raphael> +1
11:42:43 <silvia> can we come up with a meta production rule on fragments, something like mediafragment = [name = value]*
11:42:49 <silvia> and then associate it to that?
11:42:53 <silvia> -1
11:43:41 <raphael> RESOLUTION: no extensionsegment to be added in the spec
11:43:58 <raphael> close ACTION-189
11:43:58 <trackbot> ACTION-189 Put the top-level production rules back into the document (in section 4.3.5 or 4.1) closed
11:44:05 <silvia> we need to improve that part of the spec
11:44:16 <raphael> Results: 4 against, 1 for, 1 abstain
11:44:29 <silvia> rejecting the solution doesn't mean that the topic is solved
11:45:13 <raphael>  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 
11:45:32 <foolip> -1
11:45:43 <silvia> +1
11:46:11 <silvia> zakim, unmute me
11:46:11 <Zakim> silvia should no longer be muted
11:46:42 <silvia> -1
11:46:49 <raphael> Results: 5 against, 1 abstain
11:47:03 <silvia> sorry :)
11:47:08 <silvia> zakim, mute me
11:47:08 <Zakim> silvia should now be muted
11:47:15 <foolip> Zakim, mute me
11:47:15 <Zakim> foolip was already muted, foolip
11:47:18 <raphael> RESOLUTION: we just ignore values and units we do not understand
11:48:11 <raphael> 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
11:48:30 <foolip> +1
11:48:34 <silvia> +1
11:48:49 <davy> +1
11:48:49 <jackjansen> +1
11:48:58 <raphael> 0
11:49:11 <Yves> =0
11:49:18 <raphael> 4 for, 2 abstain
11:49:21 <raphael> 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
11:49:29 <jackjansen> -1
11:49:31 <Yves> +1
11:49:33 <davy> -1
11:49:51 <silvia> +1
11:49:54 <foolip> +1
11:49:58 <raphael> +1
11:50:31 <raphael> RESOLUTION: The default and only behavior of #xywh=10,10,10,10 is cropping
11:50:38 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
11:50:55 <silvia> you miss the important part in that resolution: "when rendered"
11:51:16 <raphael> 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
11:51:21 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
11:51:27 <foolip> zakim, mute me
11:51:27 <Zakim> foolip was already muted, foolip
11:52:20 <raphael> ACTION: troncy to edit section 7.1 for taking into account the cropping resolution
11:52:20 <trackbot> Created ACTION-198 - Edit section 7.1 for taking into account the cropping resolution [on Raphaël Troncy - due 2010-11-09].
11:53:26 <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.
11:54:59 <silvia> foolip, that is the meta rule I tried to suggest above
11:55:33 <silvia> Yves, do you think the production rule can be changed accordingly?
11:55:40 <foolip> silvia, indeed
11:55:47 <raphael> Yves thinks that this resolve nothing
11:56:32 <silvia> you can then make name and value utf8string
11:57:20 <Nobu> Nobu has left #mediafrag
11:57:23 <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'
11:57:40 <foolip> Of course it's not the whole solution, it's step 1.
11:58:04 <silvia> yeah, you continue with what is there, just as a type of namevalue
11:58:05 <Yves> the algorithm should say that 1/ cut at &, then name=value, 3/ it's utf-8, 4/ if npt do this...
11:58:17 <Yves> but that is orthogonal to having the grammar saying what are the valid values
11:58:25 <foolip> With this grammar, there's no need for the first algorithm in section D.
11:59:14 <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
12:01:24 <foolip> I heard.
12:01:35 <foolip> But, I think it would be more fruitful to actually see what the alternative is.
12:02:20 <silvia> zakim, unmute me
12:02:20 <Zakim> silvia should no longer be muted
12:03:12 <raphael> 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
12:03:37 <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
12:03:49 <Yves> however, a parsing algorithm might perfectly well say that
12:04:03 <Yves> those are different things 
12:04:21 <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.
12:04:53 <Yves> the grammar can operate on the splitting of '&' as otherwise <nptname> = <trackvalue> would be ok
12:04:58 <raphael> [meeting adjourned]
12:05:03 <RRSAgent> I have made the request to generate http://www.w3.org/2010/11/02-mediafrag-minutes.html raphael
12:05:11 <Zakim> -silvia
12:05:17 <Zakim> -foolip.a
12:06:53 <foolip> Yves, the idea is to have pairs of grammars, one for the name (just "t") and one for the value (npt:bla bla bla)
12:07:33 <silvia> (just want to note that I don't think we've reached the end of this discussion yet and I still be believe we can find an agreeable solution)
12:07:49 <foolip> The problem looks pretty simple to me, so I agree :)
12:25:32 <dsinger> dsinger has joined #mediafrag
12:42:24 <homata> homata has joined #mediafrag
12:44:41 <raphael> raphael has joined #mediafrag
12:44:55 <hidetaka> hidetaka has joined #mediafrag
12:58:43 <Nobu_> Nobu_ has joined #mediafrag
14:56:20 <Nobu> Nobu has left #mediafrag
15:04:14 <foolip_> foolip_ has left #mediafrag