RE: Why use time as a unit of measurement? (was: Proposal 0.0)

John, friends

I think we are looking at two different scenarios here, but I see some light.

Scenario A:  a timed-text stream is treated the same as an audio 
stream or a video stream;  it has a natural (intrinsic) duration, and 
can be layed up in parallel with other such streams.  In this case a 
SMIL 'par' construct works fine, just like it does for audio with 
video, and duration-based timing makes sense also for each 'element' 
in the text stream.

Scenario B:  text elements must appear when triggered by an external 
stimulus, such as the correct time-code appearing.  In this case, the 
text elements can NOT be treated as concatenated elements with 
duration;  each is, in some sense, a little presentation in its own 
right.  The right SMIL construct here is a 'par' with the video of a 
sequence of little text constructs, each of which has a start 
'trigger' that is defined.

In both cases, I believe that the synchronization 'layup' can and 
should be represented at the level that provides that (e.g. SMIL).

If the 'seq' construct in timed text (assuming there was such a 
thing) had a 'trigger' construct which relied on the video time-code, 
there is a layering problem;  that 'video' is not talked about in the 
pure timed-text document.

However, it seems that if we use XML it might be possible to 
construct a document which uses both the SMIL and timed text 
namespaces, and which combines the timed text element definitions and 
the SMIL layup in one XML document.  This would have other advantages 
too (it's already a pain the number of loads/stream-opens one has to 
do with SMIL, and it ought to be possible to embed the text in the 
SMIL to avoid yet more for small text captions etc.).
-- 
David Singer
Apple Computer/QuickTime

Received on Thursday, 13 February 2003 15:49:30 UTC