RE: TextTrackCue discussions

I don’t see merit in designing for the short term without at least understanding how it fits for the long term.  It may be we stage the rollout of this, we have already decided this is a separate document from 1.1, but I want to at least make sure the API is complete.

Having said that, in the short term I see no particular need for a TTMLCue object. If there is no typed wrapping of its contents, and no means to generate or utilise them as part of the HTML API, what would be the point over and above a generic cue?  If we aren’t modelling the TTML process, then referencing a file and the generic track and cue class provide adequate access.


From: Glenn Adams [mailto:glenn@skynav.com]
Sent: 24 July 2013 16:04
To: Sean Hayes
Cc: Silvia Pfeiffer; TTWG
Subject: Re: TextTrackCue discussions


On Wed, Jul 24, 2013 at 5:33 AM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
I don't see why the two parts would be in different documents; their functionality can be clearly labelled, and the APIs overlap so it makes sense to me to be in the same document. No I don't see this as the basis for inter-conversion.

Actually, I think I'm with Silvia on this. There is a stronger, near-term need for acceptable, implementable TTMLCue/TTMLRegion interfaces than holds for a TTMLElement and derived TTML DOM types.

Technically, any derived types (of TTMLElement) serve as convenience mechanisms (syntactic sugar), that is, unless there is a desire to expose computed state, e.g., computed style sets, flattened start/end time, reference to corresponding cue object, etc, but these methods/attributes could be hung off the TTMLElement interface as well.


For the <track> model, TTML maps intermediate synchronic documents to the cue list API.
The API includes the ability to:

1 Create a TTML track (has a DOM for empty document)
2 Create a TTML DOM either from an XML source document or ab-initio.
3 Get/Set the TTML DOM on the track object
4 Generate a TextTrackCueList corresponding to the loaded TTML DOM (i.e. populate the cues attribute)
5 Generate a TTML DOM from the TextTrackCueList.
6 Append a newly created cue to the list of cues.
7 Add the track to the video list of tracks.

If all you are interested in is tracks and cues, you can just use 1, 5, 6 & 7.
If you want to use the features of TTML you can use 1, 2.3 & 4 & 7.
If you want to preserve a list of cues as TTML you can use 5.

The change I was contemplating was to eliminate the TTMLCueXX objects so that the getCueAsXml() method would simply return an untyped DOM Element, and you would use the tagName to figure out what it was. This might make it more difficult to support #6, and therefore possibly make #5 redundant.



-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>]
Sent: 24 July 2013 04:09
To: Sean Hayes
Cc: Glenn Adams; TTWG
Subject: Re: TextTrackCue discussions
On Wed, Jul 24, 2013 at 12:13 AM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:
> Yes, the focus of the API is both a full TTML DOM and a mapping to the
> Cue list from HTML. TTML is indeed similar to SVG or MathML, and might
> conceivably one day be embedded in HTML in the same way. However even
> absent that, authoring and transcribing tools will be more interested
> in the former, while play-out engines may be more interested in the latter. I also put in a bridge between them, so that for example it is possible to create the TTML file from a list of live cues.  TTML markup is of course a lot richer than just time-aligned cue sequences; although such can be generated from a TTML file.

Right, that makes more sense now. Could you separate the two APIs into two different documents? I'm asking because one of them is relevant to browser vendors for the <track> element and the other is relevant for other applications which don't care about the <track> API. So, it would be good to keep them separate.


> I don't really see the TTML Dom part having an analogue in WebVTT, so
> I'm not especially concerned with consistency there; I'd like it to
> look and feel more like the HTML/SVG/MathML types of DOM so I modelled
> the main TTML DOM after
> http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html which
> has types for all the elements. I haven't put in all the attributes in
> the TTML version yet, which is why it perhaps looks a little odd as is

Indeed, the WebVTT is not trying to create WebVTT DOM. I hope there is no expectation that it will and that the basis for a conversion between WebVTT and TTML is such a DOM.


> For the Cue centric part, I guess it's a case of whether you prefer
> typed or untyped hierarchies. If the style-du-jour is untyped, then
> I'm fine with an enum of element names. On reading it's mostly just
> the difference between using typeof operator or matching an attribute
> against an enum. While I definitely foresee people building TTML files ab-initio in browser based applications; I guess they are less likely to build lists of cue objects (depending on how we solve the problem of live captions). I could definitely see reducing the cue representation types down to a single type with an enum, but I did it the other way for consistency.

I don't follow. Are you saying that for <track> API TTML cannot follow the text track model as defined in the HTML spec
(http://www.w3.org/html/wg/drafts/html/CR/single-page.html#text-track-model)
with cues and cue lists?


Thanks,
Silvia.