RE: TextTrackCue discussions

It's the only thing that is required for a JS dev to get access to the
content and rendition of a TTML file supplied through a <track> element.

The whole point of the track API in HTML is to make it simple to support
cue import and rendering. Thus, there is no need for a massive amount of
new elements and objects - just this one object would make all the
difference for TTML.

Silvia.
 On 25 Jul 2013 03:12, "Sean Hayes" <Sean.Hayes@microsoft.com> wrote:

>  OK, the API defines TTML cue, and I’m fine with replacing the TTMLCueXX
> clases with Element. ****
>
> But TTMLCue has no merit or functionality in isolation. I don’t see us
> publishing a document in which we only define TTMLCue.****
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* 24 July 2013 18:09
> *To:* Sean Hayes
> *Cc:* Silvia Pfeiffer; TTWG
> *Subject:* Re: TextTrackCue discussions****
>
> ** **
>
> TTMLCue is the primary interface we need. All the others can be given
> lower priority. The constructor defined for the interface object can be
> used to construct. The getCueAsHTML() method will be defined to return the
> desired HTML/CSS rendition.****
>
> ** **
>
> On Wed, Jul 24, 2013 at 10:58 AM, Sean Hayes <Sean.Hayes@microsoft.com>
> wrote:****
>
>  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>
> 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.****
>
>   ****
>
>  ** **
>