- From: Dave Singer <singer@apple.com>
- Date: Thu, 13 Feb 2003 12:47:07 -0800
- To: Johnb@screen.subtitling.com, public-tt@w3.org
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