W3C home > Mailing lists > Public > public-media-fragment@w3.org > July 2010

Re: Media Fragments URI parsing: pseudo algorithm code

From: Philip Jägenstedt <philipj@opera.com>
Date: Thu, 08 Jul 2010 10:54:27 +0200
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: "Yves Lafon" <ylafon@w3.org>, "Bjoern Hoehrmann" <derhoermi@gmx.net>, public-media-fragment@w3.org
Message-ID: <op.vfioc1kaatwj1d@philip-pc>
On Wed, 07 Jul 2010 23:31:29 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

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

That sounds just about like what I had intended, although I don't think  
there's any need to do a head request. No matter what the beginning of the  
file will be needed to set up the decoding pipeline, and together with  
that data we also get the MIME type.

It should be noted though, that in practice I doubt any implementation is  
going to wait for updated MIME registrations references MF before  
implementing this.

Philip Jägenstedt
Core Developer
Opera Software
Received on Thursday, 8 July 2010 08:55:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:45 UTC