RE: some points w.r.t. streaming and buffering scenarios

I don't think anyone need to worry about whether an XML based
format will be defined for TT: it will, and that will be our
primary representation form. Of course, this will not preclude
that it take other concrete forms either, and we may or may
not define such alternate forms.

G.

> -----Original Message-----
> From: Charles Wiltgen [mailto:lists@wiltgen.net] 
> Sent: Saturday, February 08, 2003 9:01 AM
> To: List EUR W3C Timed Text
> Subject: Re: some points w.r.t. streaming and buffering scenarios
> 
> 
> 
> Al Gilman wrote...
> 
> > We want to [...] use XML for what it helps us with but not 
> slavishly 
> > use XML if in the end it is seriously getting in the way.
> 
> It would be an interesting choice to burden TT with a new 
> format that's not well-understood, doesn't have wide support 
> in authoring tools, languages and OS vendors, etc.  I know 
> that I won't personally have any use for TT if it's not 
> XML-based, and in my experience most people will feel the same way.
> 
> > The requirements for 'capture' are more severe than for 'authoring.'
> 
> The requirements of /the TT format/ for realtime-captured 
> text are actually much simpler and more straightforward than 
> those for "authored" timed text presentations.
> 
> > The TT format should meet the needs of the MMI group to 
> support real 
> > time collaboration among geographically distributed people.
> 
> A file format can't support realtime collaboration, but tools 
> that use that file format can.
> 
> -- Charles Wiltgen
>    <http://playbacktime.com/>
> 
>

Received on Saturday, 8 February 2003 12:03:20 UTC