W3C home > Mailing lists > Public > uri@w3.org > June 2003

Re: temporal URI fragments

From: Martin Duerst <duerst@w3.org>
Date: Wed, 25 Jun 2003 09:34:48 -0400
Message-Id: <4.2.0.58.J.20030625092814.04b90450@localhost>
To: Silvia.Pfeiffer@csiro.au, LMM@acm.org
Cc: Silvia.Pfeiffer@csiro.au, uri@w3.org, Conrad.Parker@csiro.au

At 16:33 03/06/25 +1000, Silvia.Pfeiffer@csiro.au wrote:

>>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).

But there are time-continuous data streams that are not sampled.
Animation (e.g. SMIL animation or SVG animation) is a typical
example. Your XML example also doesn't need to have a fixed
sampling rate.


>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.

Of course there are other ways. But if there is one way that works
in all cases, why make it unnecessarily complicated.

By the way, Larry wrote 'seconds, in floating point'. I think
this should just be a decimal notation, not including exponents.


>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.

Why? Is there any difficulty for the server (or the client) to do the
calculations? Also, the faster our computers get, the more we will
probably move away from a few fixed sampling rates.


>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.

Does that say it's sampled at 60 fps? or what?

Regards,    Martin.
Received on Wednesday, 25 June 2003 09:41:26 GMT

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