Re: temporal URI fragments

Hi Larry, all,

Larry Masinter wrote:
>>Oh, I'm sorry. I believe there is a misunderstanding. I am not asking to 
>>put the temporal URI fragment specification into the Generic URI 
>>Specification RFC. All I am asking for is to allow in RFC2396 that 
>>fragments can be interpreted at the server side after all other 
>>operations have been performed on the resource.
> 
>  
> I don't understand how this happens. The client gets the URI reference
> and is attempting to resolve it. It splits at the "#" and does something
> with the two sides. There's no way to guarantee that the client
> will send the fragment to the server except in extraordinary
> circumstances, though. If the URI is "file:", for example, there's
> no server to send it to. If the URI is "http:", there's no protocol
> in HTTP to send fragment identifiers.  Maybe if the URI is "rtsp"
> and the actual data is temporal, you might be able to get a temporal
> fragment?

Here's how it may happen:
The client decides if it wants to split off the bit after "#" (as all 
existing Web browsers do) or not; if it splits it off, we have the 
existing situation where the server doesn't get the fragment and nothing 
is different (e.g. http://foo.bar/videoresource.mov#@npt=20 gets turned 
into http://foo.bar/videoresource.mov).
If the client sends the URI reference including the fragment to the 
server, the server deals with it, e.g. the appropriate apache module for 
the specific resource. This is ok as the generic URI specification 
requires fragment identifiers to be dependent on a content (or resource) 
type.

Sending the URI including fragment to a server is already possible 
currently with e.g. telnet and apache, where it works for any scheme be 
that file, http or other. We have now some code up at 
http://www.annodex.net/software/ . If you look at the apache module, 
you'll see how it works for a XML file where each tag has a time 
associated with it and you can ask for a subrange of tags based on that 
time. If set up, testing with a samle test.cmml file works with these 
commands:

telnet localhost 80
GET http://localhost/test.cmml#npt=20-40 HTTP/1.0

This returns only those tags that belong into this time range.


>>Why would that be any more fragile than the mime types?
>>For audio and video there are probably no other time schemes that are 
>>needed. But there are many other time-continuously sampled data file 
>>types which we have no knowledge of, e.g. the above mentioned data of 
>>physics experiments. If somebody requires a time scheme that is useful 
>>for another type of time-continuous data and that does not exist yet, 
>>he/she would write another I-D that explains this time scheme and its 
>>resolution and asks for registration with IANA. If it gets accepted, 
>>servers will support that scheme over time.
> 
> 
> Why not make the fragment identifier independent of the sample
> rate? Aren't there situations where you might want to send
> different sample rates depending on the bandwidth of the
> connection? Or situations where there is timed data that isn't
> 'sampled'? I'm not sure why 'seconds, in floating point, to
> any accuracy desired' isn't a better design as far as interoperability
> might go.

Every time-continuous data stream is sampled when getting digitised and 
is usually sampled at a constant sampling rate (e.g. 44100 Hz for 
audio). When it is encoded for transmission, this sampling rate is 
normally not touched. Instead, the bitrate is reduced through 
compression as much as necessary in order to accommodate for lower 
bandwidths. There are encoding algorithms that can produce variable 
bitrate, but the sampling rate of the file is usually still not touched.

Now, for the fragment, the most generic way to identify a time offset is 
indeed 'seconds, in floating point, to any accuracy desired' and "npt" 
supports that. However, there are types of data for which people have 
found other ways for referencing temporal offsets.

The SMPTE specification is such an example. It originated through the 
way in which analog video is produced, where picture frames follow each 
other and the correct playback speed identifies the framerate (which is 
the "sampling rate" for video). In the analog situation, it made more 
sense to count frames than to give temporal offsets and therefore the 
SMPTE label was invented. The whole video industry, even in the digital 
age, is still heavily using these time labels and therefore anything to 
do with digital video should be able to support these temporal 
specifications. The SMPTE fragment offsets are actually not dependent on 
the sampling rate of the digital video that they refer to, such that if 
there is a video sampled at e.g. 25 fps, you may still put a framgent 
offset of e.g. #@smpte-60=00:01:05.20 on it. Therefore, the fragemnt 
identifier is independent of the sampling rate of the data.

Best Regards,

Silvia.

Received on Wednesday, 25 June 2003 02:33:37 UTC