Re: Processing requirements

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.


> For each dimension we just define the ABNF syntax (already done, just
> needs to be separated from the name-value part) and say something like "if
> the name is 't' and the value is a valid production of the timeparam syntax,
> then..." and do approximately what we do today.
>
> We also encourage other specifications to reference these definitions if
> they want MF to be valid for that media type. It's best if they reference
> the name/value pair definition too, but it's still *possible* to reuse only
> this section and define the name-value mapping otherwise, e.g. as parsed
> from "Content-Range: t:npt 11.85-21.16/653.791" (the parsing for that header
> needs to be defined too of course).
>
> Does this seem reasonable?

Sounds reasonable to me.

Cheers,
Silvia.

Received on Tuesday, 5 January 2010 02:19:20 UTC