W3C home > Mailing lists > Public > public-media-fragment@w3.org > January 2009

Re: ISSUE-2: What is the mime type of a media fragment? What is its relation with its parent resource?

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 27 Jan 2009 17:44:03 -0500 (EST)
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
cc: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
Message-ID: <Pine.LNX.4.64.0901271736110.10249@ubzre.j3.bet>

On Tue, 27 Jan 2009, Silvia Pfeiffer wrote:

> On Tue, Jan 27, 2009 at 11:26 PM, RaphaŽl Troncy <Raphael.Troncy@cwi.nl> wrote:
>> ISSUE-2: What is the mime type of a media fragment? What is its relation
>> with its parent resource?
>> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/2
>> Raised by: RaphŽl Troncy
>> Related to a discussion started by Guillaume [1].
>> A media fragment URI can be used for addressing, for example, a particular
>> audio track of a mkv movie, or a particular key-frame of a video. What is
>> the resulting mime type of the secondary resource specified by the fragment
>> (audio, thumbnail, text)? Should we specify it in the recommendation?
>> What RFC3986 does say about the mime type of a fragment [2]?
> The mime type is information that is provided by the server through
> http to the client. It relates to a resource. I wonder what happens if
> we specify a jpg thumbnail extract from a video through a fragment
> identifier ... since a fragment only identifies a subresource and not
> a new resource, we may not be able to do so. Yves, what do you think?

The issue is not as simple as it look. First a URI can have multiple 
representations using different mime types (see Vary: in HTTP), of course 
you may have a Content-Location to indicate a URI to access directly this 
representation, it is not always sent, or even not always doable.

Also a fragment is computed relatively to the representation of the 
resource, so according to its mime type, so obviously in that case, 
sending only the fragment with a new mime type blurs the boundaries 
between regular content-negotiation (see above), and fragment processing. 
So the client have no way of figuring out which case is the right one.

For me we should stick to fragments only when the returned content would 
have the same mime type as the original, and another URI for a "fragment" 
(in the video/audio/whatever content meaning of "fragment") of the main 
resource in another mime type. In that case, using a Link: header to 
indicate that it is a sub-part of a bigger resource would be the easier 
way of giving the information to the client.

>> Side issue: in case we create a new resource (i.e. using the query '?'
>> parameter instead of the fragment '#' parameter), how do we make explicit
>> the relationship with the parent resource it was extracted from?
> By leaving out the query part, we arrive at the parent resource.
> Specifying the parent resource should not be a problem for either
> query or fragment, I would say.
It can be a uery or a / or whatever you want, having a template for doing 
this would be useful to deploy thing, but not more than that.

>> Do we use Link: rel="part_of" <video_uri> as suggested by Yves [3]?
> I am not even sure we want to do these kind of URIs:
> http://www.annodex.net/cmmlwiki/OSSForum-Trailer.png?t=0:02:10
> They should really be something more like:
> http://www.annodex.net/cmmlwiki/OSSForum-Trailer.anx?t=0:02:10&type=image/png
> What do people think?
> Cheers,
> Silvia.

Baroula que barouleras, au tiťu toujou t'entourneras.

Received on Tuesday, 27 January 2009 22:44:13 UTC

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