W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

subview syntax (Re: Combining media fragments with other time-clipping methods)

From: Conrad Parker <conrad@metadecks.org>
Date: Sat, 29 Nov 2008 09:04:26 +0900
Message-ID: <dba6c0830811281604t63334023k8b169264edc72fb6@mail.gmail.com>
To: "Media Fragment" <public-media-fragment@w3.org>


2008/11/27 Dave Singer <singer@apple.com>:
>> On 26 nov 2008, at 01:27, Silvia Pfeiffer wrote:
>>> Hi Jack, all,
>>> This is indeed a very fundamental problem and has to do with exposing
>>> the context of the resource or not. I am very torn on this issues.
>>> For example, when a browser plays back
>>> http://www.example.com/myvideo.ogg#t=20s in a Web browser for a HTML5
>>> video element, would we want to see the timeline with an offset or
>>> without?
> t=20s could be:
> * a clip from 20s to 20s
> * the whole myvideo, but start playing at 20s (as if the user had dragged
> teh slider to 20s before playback)
> * 20s to the normal end of the media, with material before 20s removed
> The first is not very useful, but both the others are.  However, the second
> is not a fragment, but a start-playing-at.

I think it is useful to distinguish between these two with syntax. The second
(start playing at) is an instruction from the user to the UI. This is where
the #fragment syntax makes sense.

The third (request media from 20s onwards) is a request from the user
agent to the server. I think this is where a query parameter makes sense.

To see how these are useful, think of a site like youtube. A user can
add "#t=20s" to the URI of the web page to make the embedded video start
playing from there, without re-loading the page. Internally, the UI might
use the server request "myvideo.ogg?t=20s" in order to retrieve the video
data to render.

In such a use-case, there's no need to expose the query syntax to the
user, and there's also no need to send #fragment to the server.

Received on Saturday, 29 November 2008 00:05:07 UTC

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