Re: video use-case

Hi Jack,

On Thu, Oct 2, 2008 at 8:43 AM, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
> On  1-Oct-2008, at 23:13 , Yannick Prié wrote:
> I can consider a fragment of a video as a fragment of a video. In that case
> it begins at 30s, I can explicitly manipulate both the fragment and the
> video (e.g. jump to a frame before the fragment beginning, let's say at
> 20s).
>
> This is, in my view, a completely different issue. I tend to think of this
> as referring to the fragment "in context", whereas the previous use case was
> referring to the fragment "out of context". But: these are terms we're using
> internally, if anyone has better/official terms: please let me know.
> An analogy outside of the video domain (where we actually first started
> considering this) is digital talking books for the blind. Think of an audio
> file with markers that index into an accompanying HTML document. While
> playing the audio fragment you want to render the corresponding text.
> However, the interpretation of "text.html#id12345" depends on how you are
> going to render it:
> 1) If you're sending it to a braille display you want only the content of
> the node referred to by the ID, and show that on the braille display.
> 2) If you are sending it to a normal display (for people with limited vision
> or dyslexia) you want to render the whole page and only scroll/highlight the
> selected area.
> The first use case is out-of-context, the second in-context. Often, as in
> this example, the choice can only be made by the user agent. And making the
> wrong choice either leads to horrible inefficiency (architecture providing 2
> when 1 is needed) or a really bad user experience (architecture providing
> only 2 when 1 is needed).
>

That's a very interesting example.

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.

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.

Cheers,
Silvia.

Received on Monday, 6 October 2008 10:04:20 UTC