Re: TextTrackCue discussions

On Wed, Jul 24, 2013 at 5:33 AM, Sean Hayes <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]
> 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>
> 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.
>
>
>