RE: Interactive Television

Hello Silvia,
I like the idea about a new kind or kinds, possibly "xml" and/or "json". Those could be catchalls for usage scenarios beyond the other kinds of subtitles, captions, descriptions, chapters and metadata. Another possible kind is outlines which resembles chapters.
Your example about DHTML overlays with hyperlinks sounds interesting; DHTML overlays are possible wherever text and graphics presently occur atop video from video post-production techniques and new enhanced features are possible with hypertext. Video post-production techniques can make use HTML5 video capabilities, DHTML and overlays and so doing might provide for entirely new features.
I think that more kinds alleviates a misunderstanding that under discussion was some sort of alternative to WebVTT. WebVTT seems apt for its set of kinds and could even be of use in convergence scenarios such as digital cable. New kinds for HTML5 video tracks, "xml" and/or "json", can allow for more Flash-like functionality with HTML5. By specifying an XML format with at least attributes for temporal intervals, any XML that makes use of that XMLNS could include time synchronization data that <track/> expects.
With regard to HTML5 video, it seems that new kinds are exciting to discuss.  
Kind regards,
Adam Sobieski

 > From: silviapfeiffer1@gmail.com
> Date: Thu, 11 Aug 2011 14:40:40 +1000
> Subject: Re: Interactive Television
> To: scott.bradley.wilson@gmail.com
> CC: adamsobieski@hotmail.com; public-web-and-tv@w3.org
> 
> Hi Scott, Adam,
> 
> On Wed, Aug 10, 2011 at 12:10 AM, Scott Wilson
> <scott.bradley.wilson@gmail.com> wrote:
> > On 9 Aug 2011, at 14:27, Adam Sobieski wrote:
> >
> > Scott Bradley Wilson,
> >
> > Upon reading the WebVTT specification, it seems that even more HTML5 tags
> > are possible in video transcripts. In particular, hyperlinks and multimedia
> > object references. The computer as teleprompter with hypertext idea,
> > illustrated in point 3, indicates how hypertext might come to be in a video
> > blog transcript. Other possible techniques include speech recognition and
> > video post-production software.
> >
> > In addition to text formats, XML and hypertext varieties of video tracks are
> > of interest. Web development scenarios include combinations of video tracks
> > with DHTML techniques. With something like <video ...><track kind="metadata"
> > type="xml/temporal" onplayheadenter="callback1" onplayheadexit="callback2"
> > src="file.xml"/></video>, multiple XML tracks can be synchronized to the
> > playhead. The JavaScript event object can include XML fragments in the data
> > structure.
> >
> > I don't think we've really explored what we can do with <track> and WebVTT
> > yet. WebVTT provides a synchronised text track useful for subtitle and audio
> > description with some formatting capabilities (position and style).
> 
> Yes, I agree. We should not invent another format to use in <track>
> which browser will not implement support for. The WebVTT file has been
> specified with sufficient flexibility to allow for such extensions as
> timed metadata with hyperlinks and all the bells and whistles. It
> won't parse as a caption or subtitle track, but as a metadata track.
> 
> 
> > The
> > reason it exists is to provide authors with a consistent text track format
> > to expect in web documents (rather than the large number of competing
> > subtitle formats around).
> 
> Yes, it's a platform for extensions.
> 
> > However, though it has been published by WHATWG it
> > hasn't been taken up by W3C yet.
> 
> We're working on that: http://www.w3.org/2011/05/google-webvtt-charter.html .
> 
> > The <track> element can reference any content type, though it does expect it
> > would contain time synchronization data.
> > I suspect many use-cases could be realized by adding extensions to WebVTT -
> > e.g. adding links to support contextual advertising overlays, or events to
> > trigger web intents [1] such as opening an EPG information entry.
> 
> I'm wondering if we should standardise something more general - such
> as timed JSON in cues. Then we can add any metadata format into it and
> it can get exposed easily to JavaScript.
> 
> If we are thinking of more concrete use cases - such as overlayed
> annotations with hyperlinks - we should consider introducing a new
> track @kind value for this and some markup.
> 
> Cheers,
> Silvia.