Re: A new proposal for how to deal with text track cues

On Fri, Jun 14, 2013 at 5:24 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Thu, Jun 13, 2013 at 1:01 AM, Glenn Adams <glenn@skynav.com> wrote:
>


> > At this point, I believe it would be wrong to characterize TTML and VTT
> as
>  > simply two different serialization formats of the same feature set.
>
> Agreed for captions. I believe you will find that when you specify
> chapters, descriptions, or general metadata in either of them, you
> will get out the exact same data and therefore they are two different
> serializations for the same data.
>

If that is possible, then I agree it is a good goal, though I'm certain
there is metadata that will remain in TTML non-standard, namespace specific
extensions. That is part and parcel of the extensibility goals of TTML's
design.


>
> > That
> > just isn't true, and I don't know if it will ever be true given the
> > differences in goals and emphasis I cite above.  That leaves us with
> needing
> > to identify a common semantic subset of features both formats support and
> > then design a common cue interface on that basis.
>
> Not necessarily. In fact, my proposal is that they provide two
> different interfaces for captions/subtitles:
> a VTTCaptionCue and a TTMLCaptionCue. I would, however, suggest they
> should use the same interface for chapters, descriptions, and
> metadata.
>

Again, this latter is a good general goal, so we are agreed on this point.

> And
> > that brings us back to the process question of where this work will take
> > place. It is fine to discuss strawmans on this ML and the TTCG or TTWG
> ML,
> > but we need a definite home for this work where consensus can be
> established
> > and decisions taken.
>
> The basic interfaces for the <track> element are in JavaScript and
> need to be defined here in the HTML WG. The TTWG can build on them and
> should right now review whether it is possible to build on them. But
> they need to be part of the HTML specification. The TTWG should then
> indeed create the TTMLCaptionCue JS API and other JS APIs as they
> relate to TTML.
>

Except for the "need to be defined here in the HTML WG", I would agree.
Most JS APIs are being defined outside the HTML WG, e.g., DOM4, CSSOM, XHR,
WebApps APIs, and so forth. It is reasonable to consider that these
specific Cue and Track APIs be defined outside the HTML WG by parties most
familiar with the requirements and semantics of this domain, and I would
argue that the HTML WG does not include the relevant parties, or at least
there are not active here. In any case, this is somewhat like the Media
Task Force in its work on MSE and EME, the experts in those areas are not
the experts on general HTML related functionality.

G.