Re: Review of use cases and requirements

Dear Jack and all,

On Wed, 2008-11-12 at 11:04 +0100, Jack Jansen wrote:
> Here's my review of http://www.w3.org/2008/WebVideo/Fragments/wiki/Use_Cases_%26_Requirements_Draft 
> , dated November 8.
> 
> Browsing media:
> Scenario 1: I think a logical pagination here would make a more  
> powerful example, so could "20 minutes" be replaced by something like  
> topics?
> 

> Scenario 2: again, logical splitting may be more powerful. Daisy  
> books, for example, allow jumping by chapter, section, paragraph,  
> sentence.

'Logical splitting' is inherent to the media itself (i.e. if the media
is structured as a document, as in "a video document" which would rarely
be the case). In fact "logical splitting" is more the issue of "track
addressing".

Still I think you've got a point Jack : maybe we could capture what I
would call "Editorial Splitting" as new scenarios for the 'Browsing
media' use-case.

"Editorial splitting" is a more high level view (hence a good use
case) of the task of splitting timewise. The scenario consists in
giving an interesting name to a time. Let's not confuse the issue of
"naming anchors" VS the issue of "named anchors in media". 

For me, giving a "pretty editorial even logical" name to a timestamp
would just be a supplementary parameter passed in the URL syntax whether
or not we decide to support "named anchors in media types".

Examples (schematically) :

Time splitting:
video?time=T0545+0405

Logical splitting:
video?track=Chapter1

Editorial splitting:
video?time=T0545+0405&name=Down%20The%20Rabit%20Hole	
- if Media doesn't supported named anchors then we just gave an
Editorial Name to this time-place in the Media

* video?name=Down%20The%20Rabit%20Hole
- if supported i.e. the Media has Named Anchors (such as in specially
compiled Flash) then we don't need to specify the time, although it
would probably be advisable 


> Recompositing media fragments:
> This section I have the most problems with. For all of these I would  
> *not* use url fragments, but in stead use SMIL (also for scenario 1  
> and 4: SMIL tiny was done specifically for playlists). There's
little  
> added value in using url fragments here: the UA will have to
implement  
> (part of) the work anyway, so I see little advantage in specifying
>      < video src="http://example.com/myvideo.ogg#t=20-30"/>
> over
>      <video src="http://example.com/myvideo.ogg" clipBegin="20"  
> clipEnd="30"/>
> Same for spatial clipping.
> 
One instance has no context (URI-FRAG) the other instance has context
(SMIL clip start/end).
Confusing but then what happens if 
< video src="http://example.com/myvideo.ogg#t=20-30"/ clipBegin="20"
clipEnd="30">
this has added value as I see it (preserve context or not yet still
navigate or structure with SMIL). So I'd keep the use case as something
desirable and to show MediaFrag-URI and SMIL interaction.

G.

Received on Wednesday, 12 November 2008 13:31:52 UTC