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

Re: [MF-TC] Setup

From: Conrad Parker <conrad@metadecks.org>
Date: Wed, 29 Apr 2009 23:17:25 +0900
Message-ID: <dba6c0830904290717m5d40f43nb818b35f4735cd26@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Michael Hausenblas <michael.hausenblas@deri.org>, Media Fragment <public-media-fragment@w3.org>
2009/4/29 RaphaŽl Troncy <Raphael.Troncy@cwi.nl>:
> †- The ',' is mandatory in case a time segment is specified, consequently,
> TC0008 is not a legal media fragment URI. The output should be: the whole
> resource is sent and the UA seeks to 10s.
> The various empty time/segment/track/id test cases need indeed to be further
> discussed.
>> †+ TC0008, though desirable, will currently fail due to our MF Grammar
> Yes.
> Actually, TC0008 and TC0009 captures the same thing ... i.e., do not break
> the current behavior of the hash when one does not enter the media frag URI
> syntax.

Is there any particular reason for not allowing this "legacy deep linking"?

I'd suggest there is a use-case for this, where someone wants to point
to the start of an interesting scene, or a link that skips the
trailers. It actually takes quite a bit more manual work to decide on
an end point, and I think it would be fair to imply an end-point of
"the end of the resource" if none is explicitly given. In any case,
"the end of the resource" is something already known by the server, so
it's a bit redundant (even inaccurate) to force a document author to
find it out and encode it in the URL.

To clarify, if the resource on the server is 20s in duration, then I
think the offsets t=10 and t=10,20 should produce the same result.

Just today I found this interesting offset:

and, really, the movie just gets better and better from that point
onwards. Do I really need to define an end point? I wish it would
never end! but alas, as with all stories involving mutant fungus, it

Received on Wednesday, 29 April 2009 14:18:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:42 UTC