- From: Yves Lafon <ylafon@w3.org>
- Date: Tue, 7 Oct 2008 03:10:37 -0400 (EDT)
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- cc: Jack Jansen <Jack.Jansen@cwi.nl>, Yannick Prié <yannick.prie@liris.cnrs.fr>, Media Fragment <public-media-fragment@w3.org>
On Mon, 6 Oct 2008, Silvia Pfeiffer wrote:
> My understanding of the URI RFC (now at
> http://www.ietf.org/rfc/rfc3986.txt) is that a fragment is a secondary
> resource that is addressed through the primary resource. For something
> like http://www.example.com/text.html#id12345 the primary resource is
> a html page. Seeing as the URI RFC states that the fragment is not
> being communicated to the Web server, but only handled within the UA,
> this request will always mean that a Web server will return the full
> html page and the UA has to do something with the fragment.
But what prevent the client to issue a something like a range request, if
it is easy to figure out a way to request the fragment you need?
> So, the only way in which I can see this working is that the UA
> displays full-context for a screen display (as is customary), but when
> dealing with braille it strips out only the relevant part. Is that how
> it works?
>
> I'm asking this because with media we cannot work in this way, since
> we may not want the full video to download to the UA in order to apply
> the fragment offset. This is the reason why we were not able to use
> the "#" URI fragment for specifying temporal URIs, but had to use the
> "?" URI query mechanism.
# can work, but the UA has to be aware it is dealing with video and a
fragment inside this video, in that case it can optimize its requests to
the server.
--
Baroula que barouleras, au tiéu toujou t'entourneras.
~~Yves
Received on Tuesday, 7 October 2008 07:11:13 UTC