Re: Resolving TextTrackCue issues

On Sat, Sep 7, 2013 at 5:27 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Sun, Sep 8, 2013 at 3:43 AM, Glenn Adams <glenn@skynav.com> wrote:
> >
> > On Fri, Sep 6, 2013 at 11:24 PM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com>
> > wrote:
> >>
> >> On Fri, Sep 6, 2013 at 2:43 AM, Glenn Adams <glenn@skynav.com> wrote:
> >> >
> >> >
> >> > On Thu, Sep 5, 2013 at 8:19 AM, Silvia Pfeiffer
> >> > <silviapfeiffer1@gmail.com>
> >> > wrote:
> >> >>
> >> >> > Could we compared example codes?
> >> >>
> >> >> I can give you an example: if you have TTML in-band in MP4, it's
> >> >> caption content, a browser has no parser and renderer for it, but can
> >> >> in theory extract the cues from the MP4 encapsulation -
> >> >>
> >> >> - the WHATWG spec would either not expose them to JS at all, or
> expect
> >> >> them to be exposed as VTTCue objects with @kind=metadata
> >> >
> >> >
> >> > This would not work, since VTTCue interprets cues of kind metadata as
> >> > WebVTT
> >> > metadata text [1], which is most definitely incompatible with TTML
> that
> >> > has
> >> > been serialized into intermediate synchronic document instances, each
> of
> >> > which is effectively an XML document.
> >> >
> >> > [1]
> >> >
> >> >
> https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#extension-designations
> >>
> >> So this is what we have to resolve. Why do you think VTTCue of
> >> @kind=metadata can't contain TTML intermediate synchronic document
> >> instances (i.e. a XML document) ?
> >
> >
> > 1. Because WebVTT metadata text is incompatible with representing a
> > serialized TTML document entity unless one applies a transfer encoding
> > first, such as BASE64.
>
> I don't follow. Can you give an example of a serialized TTML document
> entity ? I thought it was XML and not binary?
>

(1) it can be encoded in either UTF-8, UTF-16, or any other encoding, and
contains its encoding declaration, so this effectively requires binary
(octet stream) transparency;

(2) but more problematic, it contains, even if decoded into characters,
contains LF and CR, which aren't permitted in WebVTT metadata text;


>
>
> > 2. Because TTML is not related to VTT, and pretending that TTML is WebVTT
> > metadata text just  confuses authors and implementers.
>
> Agreed - some renaming would be necessary. VTTCue could be called TextCue.
>

NO. Because VTTCue is not representative of all cue types and simply
renaming it serves no purpose. It is still VTT based.


>
> > 3. Because TTML content will not be @kind=metadata, but rather captions,
> > subtitles, descriptions, etc. In other words, a renderable @kind.
>
> If it's not parsed & rendered by the browser, according to the logic
> expressed in this thread, it is exposed as @kind=metadata with the
> semantic use expressed in @inBandMetadataTrackDispatchType .
>

That is an artificial constraint introduced by the current design which
incorrectly assumed all cue types could or would somehow be treated as in
the context of VTT semantics.

What you are suggesting is that if a UA can't natively parse/render a
particular text track format, then it should be marked as metadata
irregardless of whether that conflicts with its intended semantics.

It would be better to not constrain kind, but instead, require track mode
"disabled" if UA doesn't parse or render. This would still allow client
script to access cue content as unparsed text without restricting its @kind.


>
>
> Silvia.
>