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

Re: Media Fragments URI parsing: pseudo algorithm code

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 8 Jul 2010 09:20:04 -0700
Message-ID: <AANLkTik6XUsSZdv4SjE5L0QOVcV1sK7mGRb-Cf4ag6sO@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Yves Lafon <ylafon@w3.org>, Bjoern Hoehrmann <derhoermi@gmx.net>, public-media-fragment@w3.org
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. ;-)

Received on Thursday, 8 July 2010 16:20:58 UTC

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