RE: video use-case

Silvia, I guess you are basically right.

For some background reading see also [1] and the appendix of [2] (Diagram of the Web's Retrieval Algorithm) is also utterly useful. Please note that I've added these two references to [3], already ;)

Cheers,
	Michael

[1] http://www.w3.org/DesignIssues/Fragment.html
[2] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
[3] http://www.w3.org/2008/WebVideo/Fragments/wiki/State_of_the_Art

----------------------------------------------------------
 Dr. Michael Hausenblas
 Institute of Information Systems & Information Management
 JOANNEUM RESEARCH Forschungsgesellschaft mbH
  
 http://www.joanneum.at/iis/
----------------------------------------------------------
 

>-----Original Message-----
>From: public-media-fragment-request@w3.org 
>[mailto:public-media-fragment-request@w3.org] On Behalf Of 
>Silvia Pfeiffer
>Sent: Monday, October 06, 2008 12:04 PM
>To: Jack Jansen
>Cc: Yannick Prié; Media Fragment
>Subject: 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:21:21 UTC