Re: Turning TTML2 into Hobo Stew

We also do not believe that it is useful to bring n namespaces into TTML2.
The implication is that TTML2 spec would have to reference n external
specs.  This does not seem correct.  TTML2 need only include the equivalent
functionality for every IMSCv1 feature, not the exact feature.

On Sun, Nov 5, 2017 at 9:45 PM, Glenn Adams <glenn@skynav.com> wrote:

> As I predicted, the initial request to incorporate itts:fillLineGap into
> TTML2 (#429 <https://github.com/w3c/ttml2/issues/429>) has now
> transformed into a request to incorporate the vocabulary of every profile
> that extends TTML1 or IMSC1 into TTML2 based solely on the argument that
> "the industry does it".
>
> I find these proposals extremely troubling, and in direct opposition to
> longstanding design decisions about the nature of TTML2.
>
> Let me make clear one of those design decisions: that TTML2 will be
> syntactically backward compatible with TTML1 AND will define new extensions
> to TTML1 in existing TTML namespaces (and not non-TTML namespaces).
>
> TTML namespaces do not include IMSC namespaces, do not include EBU-TT
> namespaces, do not include SMPTE namespaces, and do not include any other
> random namespace that someone happens to claim is used by "the industry".
>
> If I was willing to consider adding a single attribute in the itts
> namespace previously, I am categorically opposed to adding attributes from
> other namespaces as well, which means, at this point, that I am
> categorically opposed to adding any IMSC namespace. So I withdraw my prior
> possible consideration of adding itts:fillLineGap, and now stand opposed to
> that original proposal.
>
> If industry defined profiles that extend TTML1 want to use TTML2, then
> they need to map their extension vocabulary to TTML2 defined vocabulary,
> changing the namespaces and names of that vocabulary as required.
>
>