Re: Turning TTML2 into Hobo Stew

Let me suggest an alternative approach to muddying the TTML2 spec by
pulling in foreign namespaces: define a profile of TTML2 and pull those
foreign namespaces into that profile. Oh, that almost sounds like
IMSCvNext, doesn't it... You can build on TTML2 in such a profile and bring
in alternative mechanisms to those defined by TTML2. You can allow authors
to use either (or both) the TTML2 defined features or (and) non-TTML2
defined extensions. You can deprecate one or the other as you wish. The
point being that this approach is already the approach followed by IMSCv1,
EBU-TT, SMPTE-TT, and others, so just continue that approach in IMSCvNext,
but don't ask that TTML2 adopt the same approach.

On Sun, Nov 5, 2017 at 10: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.
>
>