Re: Media Fragments URI parsing: pseudo algorithm code

On Wed, Jul 7, 2010 at 7:30 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Wed, 07 Jul 2010 16:19:31 +0200, Yves Lafon <ylafon@w3.org> wrote:
>
>> On Wed, 7 Jul 2010, Silvia Pfeiffer wrote:
>>
>>> 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
>>
>> You can only know it's a media resource when you dereference it.
>> http://www.example.com/map#lat=-16.5&long=-151.7 is a valid Media
>> Fragment, but it may be a fragment indicating a point in a map (for example,
>> it might even be something else).
>
> How is this relevant for unknown name-value pairs specifically? #t=10 could
> also be used on non-media resources [1]. A browser could simply not parse
> and handle the fragment component until after making sure that it's dealing
> with a whitelisted MIME type. (In practice I think that amounts to only
> considering MF when used together with <audio>, <video> or when directing
> the browser directly to a media resource.)
>
> [1] strictly speaking: resources with a MIME type that hasn't opted in to MF
> in its RFC


Maybe we can introduce the notion of URI fragment dimensions. Then we
can say that every resource can have several URI fragment dimensions.
The dimensions are then analysed wrt the mime type of the media
resource, which the UA has to determine first, e.g. through a head
request or something. At this point, it can be decided if a dimension
is recognized wrt a resource of a certain mime type and dimensions
that are not recognized are ignored.

Cheers,
Silvia.

Received on Wednesday, 7 July 2010 21:32:22 UTC