Re: Processing requirements

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

-- 
Philip Jägenstedt
Core Developer
Opera Software

Received on Monday, 4 January 2010 17:20:56 UTC