Re: Processing requirements

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