Re: Turning TTML2 into Hobo Stew

We already agreed to consider each attribute individually. I don't think the issues raised are intended necessarily to conclude with inclusion, but are there to ensure that we cover everything and come to a decision. Indeed it may be that we come to the conclusion in every case not to include the attributes in TTML2.

I would just ask that we all approach these issues with an open mind to the benefits and "disbenefits" (ugh) both for TTML2 and for IMSC vNext, and think about the needs of the constituents who will use those specifications.


From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Monday, 6 November 2017 at 07:35
To: TTWG <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: Re: Turning TTML2 into Hobo Stew
Resent-From: <public-tt@w3.org<mailto:public-tt@w3.org>>
Resent-Date: Monday, 6 November 2017 at 07:36

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<mailto: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.





----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------