Re: TextTrackCue discussions

On Sat, Sep 7, 2013 at 2:11 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Sat, Sep 7, 2013 at 5:24 PM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > On Fri, Sep 6, 2013 at 10:54 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com>
> > wrote:
> >>
> >> On Sat, Sep 7, 2013 at 12:29 PM, Glenn Adams <glenn@skynav.com> wrote:
> >> >
> >> > On Fri, Sep 6, 2013 at 6:04 PM, Silvia Pfeiffer
> >> > <silviapfeiffer1@gmail.com>
> >> > wrote:
> >> >>
> >> >> On Sat, Sep 7, 2013 at 7:11 AM, Brendan Long <self@brendanlong.com>
> >> >> wrote:
> >> >> > On 08/30/2013 07:36 PM, Silvia Pfeiffer wrote:
> >> >> >
> >> >> >> What would be the reason for hiding the actual format that the
> >> >> >> browser
> >> >> >> parsed from the JS developer? Why wouldn't we specify another
> >> >> >> interface
> >> >> >> for
> >> >> >> such a parsed format that is actually able to give the JS
> developer
> >> >> >> more
> >> >> >> specific information/attributes about the Cue format just like we
> >> >> >> did
> >> >> >> with
> >> >> >> VTTCue?
> >> >> >
> >> >> > Because it's too specific. Right now JS developers can easily get
> the
> >> >> > raw
> >> >> > cue data,
> >> >>
> >> >> The raw cue data is only exposed in the GenericCue interface that we
> >> >> are just now proposing, or in the current W3C version of
> TextTrackCue.
> >> >> The WHATWG version of TextTrackCue does not expose the raw cue data.
> >> >>
> >> >>
> >> >> > but they need to know the type of cue to get anything useful.
> >> >>
> >> >> That's information that the @inBandMetadataTrackDispatchType of
> >> >> TextTrack contains.
> >> >>
> >> >>
> >> >> > For
> >> >> > example, if I want to know the start time of a cue, I can easily
> get
> >> >> > it
> >> >> > if I
> >> >> > know that the original on-the-wire format was WebVTT. Otherwise, I
> >> >> > can
> >> >> > hope
> >> >> > browser implementers will be consistent, but there's no standard
> for
> >> >> > what
> >> >> > that attribute might be named in other cues.
> >> >>
> >> >> There is in HTML5: the interface is called TextTrackCue and contains
> >> >> the start and end times.
> >> >>
> >> >>
> >> >> >> What cue formats do you see being supported by browsers as generic
> >> >> >> parsed
> >> >> >> cues without their own special interface?
> >> >> >
> >> >> > What I want is for all of these special classes to support a common
> >> >> > (useful)
> >> >> > interface, not a new special class.
> >> >> >
> >> >> > That's why I proposed this:
> >> >> >
> >> >> > interface WebVTTCue : ParsedTextTrackCue {
> >> >> >     attribute DOMString regionId;
> >> >> >     attribute DirectionSetting vertical;
> >> >> >     attribute boolean snapToLines;
> >> >> >     attribute (long or AutoKeyword) line;
> >> >> >     attribute long position;
> >> >> >     attribute long size;
> >> >> >     attribute AlignSetting align;
> >> >> > };
> >> >> >
> >> >> > interface TTMLCue : ParsedTextTrackCue {
> >> >> >     ...
> >> >> > };
> >> >> >
> >> >> > interface CEA708Cue: ParsedTextTrackCue {
> >> >> >     ...
> >> >> > };
> >> >>
> >> >> That looks like 3 identical interfaces, unless you have specific
> ideas
> >> >> what "..." would add?
> >> >
> >> >
> >> > TTMLCue will have at least:
> >> >
> >> > interface TTMLCue {
> >> >   DocumentFragment getCueAsTTML(); // obtain TTML intermediate
> >> > synchronic
> >> > document (ISD)
> >>
> >>
> >> I would expect that to end up in .text - makes more sense to me.
> >
> >
> > That would be a waste of effort, i.e., to serialize XML into text only to
> > expose it to JS which would have to deserialize it from text as XML
>
> I follow you up to here - after this, JS would interpret the XML and
> render it.
>
> > to
> > modify then mutate deserialize by setting text attribute than have
> > implementation deserialize once more into XML.
>
> I don't know why you would need to do all this.
>

TTMLCue will have already parsed the XML into a Document Fragment. The JS
client will manipulate this fragment. It would be very inefficient to force
the client to manipulate as a serialized text representation.

However, that isn't to say that an UnparsedTTMLCue parent interface
couldn't expose as text, or, in case UA doesn't parse, then expose only as
UnparsedTTMLCue instances.

If HTML spec doesn't define an {Unparsed,Generic}Cue interface, then we'll
define a TTML specific version of this in TTML2.


>
>
> > No, that's the last reasonable choice of exposing TTML content. It will
> be
> > parsed from XML, mapped to a sequence of TTML ISDs, each an XML document,
> > then exposed to JS in the latter form. The text attribute will remain
> null
> > valued.
>
> It would be better to not have .text at all and directly inherit from
> TextTrackCue.
>

> Assuming a browser does *not* implement TTML parsing and rendering,
> but can extract it from MPEG4 in-band. What would you expose in
> GenericCue .text ? I was under the impression that it would be TTML
> fragments as XML documents that would be included in-band in MPEG4,
> and thus .text would only need to be filled with what is extracted
> directly from the MPEG4 container.
>

If there is an {Unparsed,Generic}Cue defined in HTML spec, then that would
serve for this scenario. Otherwise, we'll defined an UnparsedTTMLCue
interface in the TTML2 spec (see my immediate prior email).

Conclusion: if TTML isn't parsed, then it should be exposed in text
(serialized XML) form, either by some generic|unparsed cue object or a TTML
specific unparsed cue object. It should not be exposed from a VTTCue as
WebVTT metadata text.




>
>
> Silvia.
>