Re: Media typing of fragments

On May 3, 2012, at 17:46 , Noah Mendelsohn wrote:
> I've just been reviewing the draft Media Fragments specification [1] and I note that it says of the Web:
> 
> "A further requirement put on a URI fragment is that the media type of the retrieved fragment should be the same as the media type of the primary resource. Among other things, this means that a URI fragment that points to a single video frame out of a longer video results in a one-frame video, not in a still image. To extract a still image, one would need to create a URI query scheme - something not envisaged here, but easy to devise."
> 
> I don't >think< I've seen anything in pertinent RFCs or in the Web Arch documents that mandates that conclusion. E.g. we use fragments to identify elements within an XML document; is an element a smaller XML document? I don't think so.
> 
> What am I missing? Is this a misunderstanding that the TAG should correct?

I don't think so. They clearly state that this is "a further requirement" that they are putting on URI fragments. In other words, they're defining the way in which URI fragments are processed within the confines of their specification. I see nothing wrong with the restriction they make as it applies to the specific fragment processing that they have devised.

The video example is a good one here. I a user agent processes #t=42,42 on a video it might logically result in a single frame, but you still want that to be playable through the <video> element and not have to switch to an image. So within the confines of their processing, I think it makes a lot of sense.

Making this more generic would be problematic, e.g. #xpath1(//foo/@bar) is unlikely to make sense as application/xml, or #someSVGElement might be better understood as image/svg+xml irrespective of the container's media type, but that spec does not define processing for those.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 4 May 2012 09:43:12 UTC