- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Tue, 5 Jan 2010 23:27:57 +1100
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Media Fragment <public-media-fragment@w3.org>
On Tue, Jan 5, 2010 at 7:18 PM, Philip Jägenstedt <philipj@opera.com> wrote: > On Tue, 05 Jan 2010 04:07:33 +0100, Silvia Pfeiffer > <silviapfeiffer1@gmail.com> wrote: > >> On Tue, Jan 5, 2010 at 1:36 PM, Philip Jägenstedt <philipj@opera.com> >> wrote: >>> >>> On Tue, 05 Jan 2010 03:18:28 +0100, Silvia Pfeiffer >>> <silviapfeiffer1@gmail.com> wrote: >>> >>>> On Tue, Jan 5, 2010 at 4:20 AM, Philip Jägenstedt <philipj@opera.com> >>>> wrote: >>>>> >>>>> On Wed, 30 Dec 2009 04:05:41 +0100, Silvia Pfeiffer >>>>> <silviapfeiffer1@gmail.com> wrote: >>>>> >>>>>> On Wed, Dec 30, 2009 at 10:51 AM, Jack Jansen <Jack.Jansen@cwi.nl> >>>>>> wrote: >>>>>>> >>>>>>> My 2 cents: >>>>>>> after thinking about it for a bit I think there's definitely a point >>>>>>> to >>>>>>> be made about separating our definition of the name/value pairs and >>>>>>> what >>>>>>> there semantics are from what their external representation is. >>>>>>> URL-fragments would then become one such representation, url-queries >>>>>>> another, and we leave a clear path for third parties defining yet >>>>>>> another >>>>>>> external representation while keeping our semantics. We could state >>>>>>> in >>>>>>> the >>>>>>> name/value semantics section that, irrespective of external >>>>>>> representation, >>>>>>> each name may be used at most once, order is unimportant, etc. (That >>>>>>> is: >>>>>>> this last sentence is my preference, if we as a group decide >>>>>>> otherwise >>>>>>> we >>>>>>> could also state that). >>>>>>> >>>>>>> But that doesn't solve the rather nasty issue of there being no >>>>>>> definitive reference for how to parse url queries and fragments, >>>>>>> which >>>>>>> is >>>>>>> demonstrated by the fact that Philip and me seem to have different >>>>>>> personal >>>>>>> views about what "the right way" is. >>>>>>> >>>>>>> Even though I'm reluctant to standardise something that has much >>>>>>> wider >>>>>>> scope than just media fragments I guess there simply isn't a way >>>>>>> around >>>>>>> it: >>>>>>> if it hasn't been done before we'll have to do it. In a separate >>>>>>> chapter, >>>>>>> with a preamble that we're doing this because it hasn't been done >>>>>>> before, >>>>>>> with the caveat that if it turns out we've done this wrong it means >>>>>>> that >>>>>>> Media Fragments 1.1 (which would adhere to a better standard for >>>>>>> name/value >>>>>>> encoding) would possibly be backward-incompatible with Media >>>>>>> Fragments >>>>>>> 1.0, >>>>>>> etc etc etc etc. >>>>>> >>>>>> I think we need to add a section that states what we build upon: the >>>>>> preconditions for parsing media fragments. I think that might solve >>>>>> Philip's problem of "processing of fragment component is still >>>>>> undefined". We don't have to say that we are standardising this, but >>>>>> we can say that it's beyond us to standardise it, that a de-facto >>>>>> standard has emerged with query parameters, and that we need to build >>>>>> on something, so we are specifying here what the basis is upon which >>>>>> we rely. If that basis should change (i.e. "&" be replaced by >>>>>> something else), the specification of name-value pairs still holds up >>>>>> and ppl should just adapt their parsing to that. >>>>>> >>>>>> Maybe that can help solve it. Philip, what do you think? >>>>>> >>>>>> Cheers, >>>>>> Silvia. >>>>>> >>>>> >>>>> Yes, this is exactly what is needed. To summarize, I would like the >>>>> following: >>>>> >>>>> We define the syntax and processing of the the de-facto >>>>> name=val&name2=val2 >>>>> syntax we have been assuming. This amounts to one ABNF syntax section >>>>> (without any media fragment syntax in it) and one algorithm for parsing >>>>> it, >>>>> which may or may not handle some syntax-invalid input depending on what >>>>> the >>>>> data we collect shows is necessary. The output of this algorithm is a >>>>> list >>>>> of name-value pairs. >>>>> >>>>> We encourage other specifications to reference this definition if they >>>>> need >>>>> something similar. >>>>> >>>>> We define "media fragments" (sans "URI") in terms of a list of >>>>> name-value >>>>> pairs. >>>> >>>> I guess that can work. I just regard "media fragments" as the abstract >>>> concept of using parts of a media resource - which can be concretely >>>> specified through those name-value pairs. If you can formulate it like >>>> this, that would be good. >>> >>> Hmmm... I'm thinking that "media fragment" is defined by the set of >>> dimensions that you get after applying the error handling to the >>> name/value >>> list. This is just terminology though and can always be changed if "media >>> fragment" already means something (as I've noted I don't really know what >>> it >>> means right now). >> >> It's not currently explicitly defined, so do what you think is best. >> I would think though that it makes sense to differentiate between the >> concept and the name-value pairs, whose application result in a >> concrete media fragment. > > The dimensions (e.g. "Normal Play Time") are defined in the syntax section > now, these are the concepts (not syntaxes) we should extract from the > name/value list, in my opinion. They're still syntax, but yes, they need to be extracted. Or rather, the way to combine them should be extracted. >> Note that we specified a media fragment as a single "mask" on a >> resource, so overlaps between dimensions would need to be resolved >> somehow >> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#side6 >> (that req needs some clarification, too). > > I don't entirely understand the requirement because I don't know what a > "fragment" is or what it means for them to overlap. Would #t=2,3&t=4,5 > overlap? If you think of a "fragment" as a byte range of the media file, it's easy to understand what "overlap" means. your example is not an overlap. > Does it amount to applying the error handling, so that e.g. > duplicate occurrences of a single dimension are eliminated? Yes. But it was not defined from an error perspective, but rather from a user perspective - what does a user have to expect when they create a media fragment URI - is the reply a single consecutive byte range, is it a set of byte ranges, and do these byte ranges potentially overlap? The idea is to define the first or the second as a media fragment. > In my thinking a > "media fragment" (when it means a set of dimensions) by definition only has > once "instance" of each dimension and therefore cannot have any overlap > within itself. So, your example above with t=2,3&t=4,5 is not a media fragment? It's maybe two media fragments? I think we haves struggled so far whether we want multiple byte ranges to be an answer to a media fragment URI or not. One byte range would of course be preferrable, but is it satisfactory? > Or are there ways for different dimensions to overlap? No, I guess different dimensions have to overlap by definition, i.e. we only retrieve what is in the intersection. > Again > I think the problem is terminology, could someone explain the requirement in > simpler terms? Hope this helped a bit. Cheers, Silvia.
Received on Tuesday, 5 January 2010 12:28:51 UTC