You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1224 lines
45 KiB
1224 lines
45 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux (vers 6 November 2007), see www.w3.org" />
|
|
|
|
<title>Media Fragments Working Group Teleconference -- 02 Nov
|
|
2010</title>
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/base.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/public.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/2004/02/minutes-style.css" />
|
|
<meta content="Media Fragments Working Group Teleconference"
|
|
name="Title" />
|
|
<meta content="text/html; charset=utf-8" http-equiv=
|
|
"Content-Type" />
|
|
</head>
|
|
|
|
<body>
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
|
|
"48" width="72" /></a></p>
|
|
|
|
<h1>- DRAFT -</h1>
|
|
|
|
<h1>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>02 Nov 2010</h2>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>Davy, Raphael, Dave_Singer, Yves, Jack, Silvia,
|
|
Philip</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>Raphael</dd>
|
|
|
|
<dt>Scribe</dt>
|
|
|
|
<dd>raphael</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="#agenda">Topics</a>
|
|
|
|
<ol>
|
|
<li><a href="#item01">1. Action Points review</a></li>
|
|
|
|
<li><a href="#item02">summarizing yesterday's
|
|
achievements</a></li>
|
|
|
|
<li><a href="#item03">2. IETF and TAG updates</a></li>
|
|
|
|
<li><a href="#item04">3. Comments on the spec</a></li>
|
|
|
|
<li><a href="#item05">4. Use of a media fragment URI in a
|
|
browser bar</a></li>
|
|
|
|
<li><a href="#item06">5. Extensibility</a></li>
|
|
</ol>
|
|
</li>
|
|
|
|
<li><a href="#ActionSummary">Summary of Action Items</a></li>
|
|
</ul>
|
|
<hr />
|
|
|
|
<div class="meeting">
|
|
<p class='phone'></p>
|
|
|
|
<p class='phone'></p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 02 November
|
|
2010</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribe: raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<h3 id="item01">1. Action Points review</h3>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Do we have Zakim set
|
|
up?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Will the France
|
|
bridge work today?</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> scribenick: davy</p>
|
|
|
|
<h3 id="item02">summarizing yesterday's achievements</h3>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Sorry, I can't hear
|
|
at all, will try the US bridge instead</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> hours in NPT time codes
|
|
will be optional</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ACTIOn-192?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/192">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/192</a></p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> SMPTE time codes that do
|
|
not match the encoding settings of the media resource result in
|
|
an error case<br />
|
|
... perhaps 416 is too strong for this case, should we change
|
|
this?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Zakim: mute me</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> send a 200 instead</p>
|
|
|
|
<p class='phone'><strong class='resolution'>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)</strong></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> => code updated
|
|
(JavaCC grammar) with optional hours</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> comment from Philip:
|
|
which pixels should we use (physical pixels or display
|
|
pixels)<br />
|
|
... we decided to use display pixels</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> CSS is not relevant
|
|
:)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> This is not a CSS
|
|
issue.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> see <a href=
|
|
"http://dev.w3.org/csswg/css3-values/">http://dev.w3.org/csswg/css3-values/</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://dev.w3.org/csswg/css3-values/#the-px-unit">http://dev.w3.org/csswg/css3-values/#the-px-unit</a></p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Yes Philip, but it
|
|
is confusing to reuse a term to mean something else that
|
|
something which has an accepted definition</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... so we are right
|
|
to define what we mean without talking to CSS pixels</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... like you said,
|
|
this has nothing to do with CSS</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Didn't we already do
|
|
that yesterday?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> yes, I'm
|
|
summarizing the discussion</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> 2nd paragraph of
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-space</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> No, only the media
|
|
resource itself has an influence</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I agree</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> css pixel latest
|
|
definitions here <<a href=
|
|
"http://fantasai.inkedblade.net/style/specs/css2.1/px-unit%3E">http://fantasai.inkedblade.net/style/specs/css2.1/px-unit></a></p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> other discussion: should
|
|
we specify how media fragments are rendered in a browser?<br />
|
|
... we created a section 7.1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0002.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0002.html</a></p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: can you
|
|
paste links to the mails/bugs you've sent?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip: see above</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> MIME type definition never
|
|
includes rendering specifications</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I disagree, I think
|
|
it's our problem.</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Dave: presentation
|
|
should be consistent in all context</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> One might say that
|
|
the problem is that we have ambiguous syntax, both for t= and
|
|
xywh=</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> no, ambiguous
|
|
semantics, rather</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I'm not sure I see
|
|
the ambiguity you're talking about</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the semantic is
|
|
unambiguous, displaying it is undefined.</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: I would like
|
|
that implementers propose both choices (show focus and
|
|
crop)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (undefined, so
|
|
ambiguous :) )</p>
|
|
|
|
<p class='phone'><cite>Dave:</cite> so that the choice is up to
|
|
the author</p>
|
|
|
|
<p class='irc'><<cite>pchampin</cite>> +1</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if the author decides about
|
|
the rendering, the rendering should be specified in the URI</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> distinction between # and ?
|
|
is not an option for rendering indications</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I observe that the
|
|
room is more and more inclined to add a "crop" keyword</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I would caution
|
|
against that, unless you have an implementor willing to
|
|
implement both xywh and crop.</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Philip, will you
|
|
only implement the crop aspect?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I know that
|
|
implementing highlight seems not very useful, but I'm not
|
|
saying that we *will* implement any other behavior.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> That's the extent
|
|
(lack of) commitment :)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> OK, so your
|
|
priority 1 will be crop (sprite) ... and of you have resources,
|
|
highlight, right?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> No, I don't think
|
|
there's a reason to ever implement highlighting, and that
|
|
maaaaybe, given resources, crop could be worthwhile</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I observe that the
|
|
group is willing to take an important decision, changing the
|
|
semantics of rendering spatial media fragments and defaulting
|
|
to crop</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Philip will
|
|
definitively implement "show focus" in context for the temporal
|
|
dimension, and possibly only "crop" for the spatial
|
|
dimension</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Uh, I never said
|
|
definite about anything.</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ok Philip :-) I
|
|
just over interpret what you have said, feel free to
|
|
correct</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> For #t=10,20 the
|
|
most useful behavior to implement is focusing, and we *might*
|
|
implement that, as you saw at FOMS</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> For
|
|
#xywh=10,10,20,20 the most useful behavior is cropping, but I'm
|
|
not sure we'd implement even that.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> It depends on what
|
|
other browser vendors think, really.</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> thanks for the
|
|
clarification</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> #xywh with cropping
|
|
is actually more useful to images than to video</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> e.g. handing over
|
|
spliced images to a JS API</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> interesting
|
|
question: what if somebody wants to highlight an area in a
|
|
cropped frame?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> you can define a
|
|
highlight window to be the cropped part</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
#crop=40,40,20,20&xywh=10,10,20,20 would work - but not if
|
|
we only allowed one</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, how?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> img src=foo z-index 0,
|
|
effect-blur + img src=foo#xywh=.... z-index 1, positionning
|
|
x,y</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and you got the
|
|
higlight</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> i would like that there is
|
|
a CSS styling attribute that indicates if its in or out of
|
|
focus</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yeah, but that's not
|
|
handed on through a URL</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we don't need any
|
|
spatial media fragments to do any of this in CSS</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> oups, no I don't
|
|
understand what you mean?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> raphael: thanks</p>
|
|
|
|
<p class='phone'><cite>silvia:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> if I read silvia,
|
|
higlighting is CSS driven, cropping is #xywh=</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> What was the last
|
|
sentence?</p>
|
|
|
|
<p class='phone'>video { temp_frag: highlight; spat_frag: crop
|
|
)</p>
|
|
|
|
<p class='phone'>an example of a CSS statement?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Let them use image
|
|
maps :)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> 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)"</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> ?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Room agrees thay by
|
|
default, the behavior should be crop</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Why should we expect
|
|
them to be consistent, when they're completely different
|
|
dimensions?</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Because that is
|
|
called "elegance"</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<h3 id="item03">2. IETF and TAG updates</h3>
|
|
|
|
<p class='phone'><cite>Yves:</cite> 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<br />
|
|
... correction: what we need to do is not writing nything<br />
|
|
... I have discussed with him and we need to write it</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> s/ng</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> > s/Larry/what we
|
|
need to do/</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Larry Masinter?</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> this document will have to
|
|
be written when we are in CR stage</p>
|
|
|
|
<p class='phone'><cite>ISSUE:</cite> Create a IETF draft at CR
|
|
stage explaining what the media fragment semantics will be for
|
|
video/*, image/*, audio/*</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> 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 <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/20/edit">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/20/edit</a>
|
|
.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> And what about
|
|
application/ogg then? Seems like a fragile approach.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> 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.</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> TAG is discussing with IETF
|
|
for enforcing them to update their rules for forcing the
|
|
definition of fragment semantics in mime type</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip, image#xywh
|
|
might be, CSS for example,</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> to define sprites</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I'm not sure how
|
|
that would work, my gut feeling is it's in the wrong layer for
|
|
it to work out.</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I don't think we will get a
|
|
review from TAG now</p>
|
|
|
|
<h3 id="item04">3. Comments on the spec</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> who is on the URI
|
|
mailing list?<br />
|
|
... are you Silvia?<br />
|
|
... I want to talk to the mail you forward</p>
|
|
|
|
<p class='phone'><cite>Discussing:</cite> <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Oct/0042.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Oct/0042.html</a></p>
|
|
|
|
<p class='phone'>See also: <a href=
|
|
"http://lists.w3.org/Archives/Public/uri/2010Oct/thread.html">http://lists.w3.org/Archives/Public/uri/2010Oct/thread.html</a></p>
|
|
|
|
<p class='phone'>The author is very confused</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> what is happening depends
|
|
on the mime type, not on the scheme<br />
|
|
... we trust Silvia to deal with this very well</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='phone'>We also received comments from the Media
|
|
Annotations WG</p><a name="action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> troncy to address comments from the
|
|
Media Annotations WG and draft a reply [recorded in <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html#action01">http://www.w3.org/2010/11/02-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-196
|
|
- Address comments from the Media Annotations WG and draft a
|
|
reply [on Raphaël Troncy - due 2010-11-09].</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, I am on the URI
|
|
mailing list</p>
|
|
|
|
<h3 id="item05">4. Use of a media fragment URI in a browser
|
|
bar</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I argue that
|
|
www.youtube.com/watch?v=xx5kBqxyaHE#t=310s should trigger a
|
|
Range Request</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 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</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> we cannot really enforce
|
|
anything</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Incidentally, #t=30
|
|
on text/html resources is the most useful, but unfortunately
|
|
not something we can standardize or implement</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (as it default to
|
|
return the whole thing back). Sending byte range requests will
|
|
add latency and be generally bad in taht case</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> but I will recommend
|
|
server developers to propagate the info from the video element
|
|
to the url bar?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> if we trigger a
|
|
speciic processing in case of html video, it should be part of
|
|
html5 then ;)</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Yes, but I doubt we
|
|
can overload fragment identifiers for HTML without breaking the
|
|
web</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
example.com/video.ogv?v=1&t=310s</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> foolip, that was not
|
|
raphael's point, his point was, what should the browser do
|
|
before knowing it's html or video</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>>
|
|
example.com/video.html?v=1&t=310s</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> without the context of
|
|
being in a video element</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> that would signify
|
|
to the server to change the @src on the first video to an
|
|
offset with #t=310s</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, we are talking
|
|
about the situation where the browser doesn't know what type of
|
|
resource it is getting</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> 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<br />
|
|
... my argument is, either you are in context (of a video
|
|
element), and then, go for recipe 1, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 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</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> or you don't know the
|
|
context (url bar), and then, go for recipe 2, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> it depends if browsers want
|
|
to implement it<br />
|
|
... that will be the case only for the time dimension, and if
|
|
UA wants to implement the seconds unit for the
|
|
Range</p><a name="action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> troncy to also add in the intro of
|
|
Section 5 a paragraph explaining the optimistic processing of
|
|
fragments (using ranges in seconds) [recorded in <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html#action02">http://www.w3.org/2010/11/02-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> 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].</p>
|
|
|
|
<p class='phone'>[coffee break]</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I didn't bring up
|
|
this topic, raphael, I do not disagree with anything you
|
|
said</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I thought we were
|
|
discussing my email and the suggestion I had for server
|
|
apps</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we are resuming
|
|
discussions and we need to be efficient<br />
|
|
... we will discuss and resolve extensibility issue in 45 min
|
|
max<br />
|
|
... and then vote on the cropping issue for spatial media
|
|
fragment</p>
|
|
|
|
<p class='phone'>Philip, Silvia, please, be on this channel in
|
|
45 min for voting</p>
|
|
|
|
<h3 id="item06">5. Extensibility</h3>
|
|
|
|
<p class='phone'>ACTION-181?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-181 -- Jack
|
|
Jansen to investigate how escaping is defined in uri spec --
|
|
due 2010-07-07 -- OPEN</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/181">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/181</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> the URI spec does not say
|
|
anything about further sub-division between delims and
|
|
sub-delims</p>
|
|
|
|
<p class='phone'><cite>See:</cite> <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0000.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0000.html</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> if we first parse between
|
|
& and =, and then do %-decode, we do the right thing<br />
|
|
... but we need to write down that %-decode must happen after
|
|
the splitting</p>
|
|
|
|
<p class='phone'>close ACTION-181</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-181
|
|
Investigate how escaping is defined in uri spec closed</p>
|
|
|
|
<p class='phone'>Section 4.1: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#general-structure">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#general-structure</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> %-decoding of
|
|
non-(delims/sub-delims) may happen anytime, so we consider it
|
|
is done for the sake of readability of the grammar</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I suggest to add this
|
|
sentence in the specification</p>
|
|
|
|
<p class='phone'>close ACTION-185</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-185 Book
|
|
zakim for the 2 days meeting of the group on Mon 1st and Tue
|
|
2nd Nov closed</p>
|
|
|
|
<p class='phone'>ACTION-189</p>
|
|
|
|
<p class='phone'>ACTION-189?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189</a></p>
|
|
|
|
<p class='phone'>Old proposal was</p>
|
|
|
|
<p class='phone'>mediasegment = namesegment / axissegment</p>
|
|
|
|
<p class='phone'>axissegment = ( timesegment / spacesegment /
|
|
tracksegment ) *( "&" ( timesegment / spacesegment /
|
|
tracksegment )</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> New proposal is:</p>
|
|
|
|
<p class='phone'>mediasegment = namesegment / axissegment /
|
|
extensionsegment</p>
|
|
|
|
<p class='phone'>extensionsegment = extensionprefix '='
|
|
extensionparam</p>
|
|
|
|
<p class='phone'>+ prose to state that a media segment cannot
|
|
be only an extension segment</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> + warning to say that
|
|
it should not conflict with an existing axis</p>
|
|
|
|
<p class='phone'>extensionprefix and extensionsegment are like
|
|
the values (pchar - the subdelims)</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> vote for changing the
|
|
top level production rules into this proposal</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +0</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I invite everybody to
|
|
vote</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> -0</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='phone'>Provisory results: 2 for, 2 abstain, 0
|
|
against</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> I will wait for the votes
|
|
of Silvia and Philip before resolving</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> next issue, how do we treat
|
|
values and units that we don't understand in dimensions of
|
|
media fragments?</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> should we allow
|
|
this?<br />
|
|
... example: #t=morning ? #t=wallclock:10,25 ?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I think we should not have
|
|
them (both)</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> I agree with Jack</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> if we get extensibility on
|
|
other axis, then I think we should have extensibility for units
|
|
and values we don't know, for consistency</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> I agree with
|
|
Yves on the consistency argument, but here practicality beats
|
|
purity.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> I agree with Jack and
|
|
Davy, we should be limited to the units and values we can parse
|
|
and not allow the rest</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> I would really
|
|
not like the extensibility but accept it for practical reasons
|
|
(hence +0). This is a bridge too far, however.</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> -1</p>
|
|
|
|
<p class='phone'>-1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ~0</p>
|
|
|
|
<p class='phone'>Provisory results: 3 against changing the
|
|
grammar, 1 abstain</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> I will wait for the votes
|
|
of Silvia and Philip before resolving</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ok, it's going to
|
|
end at 12</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> can you wait?</p>
|
|
|
|
<p class='phone'>Yes</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> thanks</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> uh, it was
|
|
apparently 12:15</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> anyway, I'll type
|
|
what I think right now</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I think
|
|
"extensibility" is not really the issue, and I don't think we
|
|
need to change the grammar for this reason</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> However, the
|
|
processing should tolerate (by ignoring) #t=morning or
|
|
#t=wallclock:10,25</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> That has nothing to
|
|
do with syntax or validity.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> So for the
|
|
extensionsegment syntax change, I would vote again, as it
|
|
doesn't fix ISSUE-19</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> ISSUE-19 requires
|
|
more sweeping changes to the spec</p>
|
|
|
|
<p class='phone'>Philip, we will wait for 12:15 you're back,
|
|
don't worry</p>
|
|
|
|
<p class='phone'>thanks for your comment, and by "again", I
|
|
guess you meant "against" ?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> yes</p>
|
|
|
|
<p class='phone'>furthermore, everybody agrees that #t=morning
|
|
or #t=wallclock:10,25 should be ignored (good point)</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> these are not and will
|
|
never be media fragments 1.0</p>
|
|
|
|
<p class='phone'>ISSUE-19?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-19 --
|
|
Parsing must be defined normatively in the MF spec itself --
|
|
open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19</a></p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> there is nothing in the
|
|
grammar that says where %-decoding and utf-8 decoding
|
|
happen<br />
|
|
... perhaps the %-decoding is specified in the uri spec</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> %-decoding is indeed
|
|
defined in rfc3986 (especially for non delims/sub-delims)</p>
|
|
|
|
<p class='phone'>Philip, it is written in 4.2</p>
|
|
|
|
<p class='phone'>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</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> let's go back to
|
|
ISSUE-19</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree with
|
|
issue-19</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think the proposed
|
|
changes are trying to realize the requirements that you wrote
|
|
in issue-19</p>
|
|
|
|
<p class='phone'>yes silvia</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Old proposal was</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> mediasegment =
|
|
namesegment / axissegment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> axissegment = (
|
|
timesegment / spacesegment / tracksegment ) *( "&" (
|
|
timesegment / spacesegment / tracksegment )</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> New proposal is:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> mediasegment =
|
|
namesegment / axissegment / extensionsegment</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> extensionsegment =
|
|
extensionprefix '=' extensionparam</p>
|
|
|
|
<p class='phone'>thanks silvia</p>
|
|
|
|
<p class='phone'>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</p>
|
|
|
|
<p class='phone'>From the section 4.2, last paragraph, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#url-serialization">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#url-serialization</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I tend to agree with
|
|
Jack</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I thought that we were
|
|
happy to have the grammar+text, and other people would work on
|
|
an algorithm</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the ISSUE-19 mentions 3
|
|
things<br />
|
|
... be rigid on the grammar to flag errors for validator ...
|
|
this is what the grammar is used for<br />
|
|
... allow graceful extensibility ... this is dealt with the
|
|
proposal change in the production rules<br />
|
|
... match what most scripting languages do currently ... no
|
|
evidence that what we have made go agains this<br />
|
|
... so I don't see why ISSUE-19 is not resolved</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> New proposal
|
|
is:</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> mediasegment =
|
|
namesegment / axissegment / extensionsegment</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> extensionsegment =
|
|
extensionprefix '=' extensionparam</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> + prose to state
|
|
that a media segment cannot be only an extension segment</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> + warning to say that
|
|
it should not conflict with an existing axis</p>
|
|
|
|
<p class='phone'>ACTIOn-189?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/189</a></p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Proposal: vote for
|
|
changing the top level production rules into this proposal</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +0</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Raphael: I invite
|
|
everybody to vote</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> -0</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Provisory results:
|
|
2 for, 2 abstain, 0 against</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... I will wait for
|
|
the votes of Silvia and Philip before resolving</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> what are you
|
|
missing?</p>
|
|
|
|
<p class='phone'><cite>Philip:</cite> it is not clear that
|
|
utf-8 decoding happen on both names and values</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> all the values and names
|
|
that are not explicitly said utf-8 strings are ASCII so utf-8
|
|
compatible<br />
|
|
... we might need to add this for extensionprefix and
|
|
extensionparam</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, I think it
|
|
needs to be added to extensionsprefix and extensionparam -
|
|
though it could be noted generally</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I would like to have the 2
|
|
votes and adjourned</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> vote for changing the
|
|
top level production rules and include the extensionsegment for
|
|
enabling extensibility</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> -</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ~0</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> can we come up with
|
|
a meta production rule on fragments, something like
|
|
mediafragment = [name = value]*</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> and then associate
|
|
it to that?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> -1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: no
|
|
extensionsegment to be added in the spec</strong></p>
|
|
|
|
<p class='phone'>close ACTION-189</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-189 Put the
|
|
top-level production rules back into the document (in section
|
|
4.3.5 or 4.1) closed</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> we need to improve
|
|
that part of the spec</p>
|
|
|
|
<p class='phone'><cite>Results:</cite> 4 against, 1 for, 1
|
|
abstain</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> rejecting the
|
|
solution doesn't mean that the topic is solved</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> -1</p>
|
|
|
|
<p class='phone'><cite>Results:</cite> 5 against, 1 abstain</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> sorry :)</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: we just
|
|
ignore values and units we do not understand</strong></p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> +1</p>
|
|
|
|
<p class='phone'>0</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> =0</p>
|
|
|
|
<p class='phone'>4 for, 2 abstain</p>
|
|
|
|
<p class='phone'><cite>Proposal:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> -1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: The
|
|
default and only behavior of #xywh=10,10,10,10 is cropping when
|
|
rendered</strong></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> you miss the
|
|
important part in that resolution: "when rendered"</p><a name=
|
|
"action03" id="action03"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> troncy to edit section 7.1 for taking
|
|
into account the cropping resolution [recorded in <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html#action03">http://www.w3.org/2010/11/02-mediafrag-minutes.html#action03</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-198
|
|
- Edit section 7.1 for taking into account the cropping
|
|
resolution [on Raphaël Troncy - due 2010-11-09].</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> My suggestion for
|
|
ISSUE-19 is still <<a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Aug/0005.html%3E">http://lists.w3.org/Archives/Public/public-media-fragment/2010Aug/0005.html></a>
|
|
and what would necessarily follow.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> foolip, that is the
|
|
meta rule I tried to suggest above</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> Yves, do you think
|
|
the production rule can be changed accordingly?</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> silvia, indeed</p>
|
|
|
|
<p class='phone'>Yves thinks that this resolve nothing</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> you can then make
|
|
name and value utf8string</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> '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'</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> Of course it's not
|
|
the whole solution, it's step 1.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yeah, you continue
|
|
with what is there, just as a type of namevalue</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the algorithm should
|
|
say that 1/ cut at &, then name=value, 3/ it's utf-8, 4/ if
|
|
npt do this...</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but that is orthogonal
|
|
to having the grammar saying what are the valid values</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> With this grammar,
|
|
there's no need for the first algorithm in section D.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I guess we have two
|
|
diverging views here: the grammar is a production rule and the
|
|
algo in section D is a dissecting approach</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> I heard.</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> But, I think it
|
|
would be more fruitful to actually see what the alternative
|
|
is.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> however, a parsing
|
|
algorithm might perfectly well say that</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> those are different
|
|
things</p>
|
|
|
|
<p class='irc'><<cite>foolip</cite>> 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.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the grammar can
|
|
operate on the splitting of '&' as otherwise
|
|
<nptname> = <trackvalue> would be ok</p>
|
|
|
|
<p class='phone'>[meeting adjourned]</p>
|
|
</div>
|
|
|
|
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
|
|
Items</a></h2><!-- Action Items -->
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> troncy to address
|
|
comments from the Media Annotations WG and draft a reply
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html#action01">http://www.w3.org/2010/11/02-mediafrag-minutes.html#action01</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> troncy to also
|
|
add in the intro of Section 5 a paragraph explaining the
|
|
optimistic processing of fragments (using ranges in seconds)
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html#action02">http://www.w3.org/2010/11/02-mediafrag-minutes.html#action02</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> troncy to edit
|
|
section 7.1 for taking into account the cropping resolution
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html#action03">http://www.w3.org/2010/11/02-mediafrag-minutes.html#action03</a>]<br />
|
|
|
|
<br />
|
|
[End of minutes]<br />
|
|
<hr />
|
|
|
|
<address>
|
|
Minutes formatted by David Booth's <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> version 1.135 (<a href=
|
|
"http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
|
|
$Date: 2010/11/02 12:05:09 $
|
|
</address>
|
|
|
|
<div class="diagnostics">
|
|
<hr />
|
|
|
|
<h2>Scribe.perl diagnostic output</h2>[Delete this section
|
|
before finalizing the minutes.]<br />
|
|
<pre>
|
|
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
|
|
Check for newer version at <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/">http://dev.w3.org/cvsweb/~checkout~/2002/scribe/</a>
|
|
|
|
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: <a href=
|
|
"http://www.w3.org/2010/11/02-mediafrag-minutes.html">http://www.w3.org/2010/11/02-mediafrag-minutes.html</a>
|
|
People with action items: troncy
|
|
|
|
</pre>[End of <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> diagnostic output]
|
|
</div>
|
|
</body>
|
|
</html>
|