Re: Media Fragments URI parsing: pseudo algorithm code

Yves, Philip,

> On Wed, Jul 7, 2010 at 3:54 AM, Philip Jägenstedt <philipj@opera.com> wrote:
>> On Wed, 07 Jul 2010 11:10:27 +0200, Yves Lafon <ylafon@w3.org> wrote:
>>
>> On identifying arbitrary name-value pairs, I am not keen on doing that.
>> http://www.example.com/foo.mov#foo=bar is _not_ a media fragment.
>>
>> Also, the fact that we are doing processing before receiving the content
>> (and hence know the mime type), means that we are doing speculation based on
>> the syntax, which is ok in most cases, especially as we designed what we
>> could do in a way that would be harmless if the assumption is wrong, but
>> assuming that every name-value pair is part of a media fragment seems just
>> wrong.
>>
>
> For those who were not on the phoneconf:
>
> No, I don't want a normalization step, as that would require performing
> percent-decoding twice. I want percent decoding to happen only once: after
> splitting name-value pairs.
>
> I would be absolutely fine with saying that e.g. #t=5&foo=bar is not a valid
> media fragment, but not with ignoring the entire fragment in such a case.
>
> Validity and processing are two different matters. A comparison with CSS
> isn't perfect, but serves to illustrate my point:
>
> body {
>  background-color: red;
>  foo: bar;
> }
>
> This is not valid CSS. However, how to process it is perfectly well defined.
> I don't know the ins and outs of CSS parsing, but the net result is that
> unknown things are ignored.
>
> So, for #t=5&foo=bar, I would expect a MF validator to warn that foo is not
> a known MF dimension


I would agree to this analysis: #foo=bar is not a valid MF
*dimension*. It is, however, a valid media fragment URI, since a media
fragment URI is given as a URI on a media resource that has a fragment
specified and we specify fragment through name-value pairs. The
fragment *dimension* is unknown under the given specification but
could be user-defined and therefore perfectly valid if both the
involved UA understands it (e.g. if some UA plugin takes care of it).

So, I actually disagree with the notion that this is no a valid MF URI
- it is a valid MF URI - it is just not a valid MF dimension.


>, but for implementations to happily ignore it. This
> allows implementations to not break completely when faced with future
> extensions. It is assumed that future extensions will not change the meaning
> of existing dimensions. Even if there were such a spec, a web browser could
> not implement it because it would break existing pages that depended on the
> old behavior.


Cheers,
Silvia.

Received on Wednesday, 7 July 2010 12:45:13 UTC