Re: Processing requirements

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.

Received on Wednesday, 30 December 2009 03:06:33 UTC