W3C home > Mailing lists > Public > uri@w3.org > March 2004

time-slice views and #fragment syntax [was: RE: fragment prose proposal]

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Fri, 12 Mar 2004 12:14:54 -0500
Message-Id: <p06020428bc779d53104a@[10.0.1.3]>
To: uri@w3.org
Cc: Silvia.Pfeiffer@csiro.au

At 1:10 PM -0800 3/11/04, Larry Masinter wrote:
>> I don't in any way disagree with what you write below or Larry's
>> comment.
>> 
>> I also don't see how it contradicts my statement that fragids
>> force one into the domain of document retrieval since no matter
>> how you model it, you cannot get from a URIref with fragid to
>> a representation of the secondary resource without *first*
>> obtaining a representation of the primary resource.
>
>There is a proposal floating around for a common fragment
>identifier mechanism for access to time-streaming resources,
>independent of the access method, whether you use rtsp: or sip: or
>http: or tv: or whatever.
>         draft-pfeiffer-temporal-fragments-02.txt
>
>
>So if there is a streaming media source of a 5-hour video
>presentation, there's a common way of accessing "3 hours
>into the video", that is independent of the URI scheme.
>

Yes, but in this draft, the interpretation of the #fragment
version is specified completely by the Internet-Draft, and
is not dependent on the type of stream encoding employed.

As Larry commented earlier, this conflicts with accessing a
slice of a MIME presentation as keyed by e.g. smil:par element ID.

That's an example of why I would recommend sticking to the query form
for time-sliced views.

A use case where you might actually want to be time-slicing a SMIL 
presentation is one where the SMIL player is a portlet and what goes 
to the client is streaming media but what the client requests is the 
play of the SMIL presentation by indicating a URI for the SMIL 
document (which serves as the head of the media tree for the 
presentation). In this case indeed we would want to have access to 
syntax for either a time slice or a structural sub-playlist reference 
by ID.

Which would remove them from relevance to this discussion.

>I'd think this would be useful even for 'info' and 'urn'.
>

'urn' perchance; 'info' I believe not.

>This isn't "document retrieval", in the sense that there is
>any MIME body for the 5-hour video, but it does still separate
>out the application of the fragment identifier from the URI
>scheme.

It is 'representation retrieval' as it can be activated to initiate 
play for a tail of the longer stream.

Al

>
>Larry
Received on Friday, 12 March 2004 12:19:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:32 GMT