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

What is the status of Silivia’s proposal?  Do we have consensus on the proposal and/or where it should be dealt with?

/paulc
HTML WG co-chair

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Friday, June 14, 2013 8:50 AM
To: Silvia Pfeiffer
Cc: public-html
Subject: 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<mailto:silviapfeiffer1@gmail.com>> wrote:
On Thu, Jun 13, 2013 at 1:01 AM, Glenn Adams <glenn@skynav.com<mailto: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.