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: Fri, 09 Jul 2010 09:42:01 +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.vfkfobghatwj1d@philip-pc.gothenburg.osa>
On Thu, 08 Jul 2010 18:20:04 +0200, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Thu, Jul 8, 2010 at 1:54 AM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> 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.
> I would hope they don't wait! But the point of finding out the MIME
> type is to find out whether it's a video or audio type that their
> application supports. Not really to check the MIME registration
> document. ;-)

Yes, the MIME type is already checked for <audio> and <video>.

Philip Jägenstedt
Core Developer
Opera Software
Received on Friday, 9 July 2010 07:42:42 UTC

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