Re: Processing requirements

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.

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).

Cheers,
Silvia.

Received on Tuesday, 5 January 2010 03:08:26 UTC