Re: Turning TTML2 into Hobo Stew

> A PR was merged in applying that: "extensions to [[TTML2]] that are specified in [[ttml-imsc1.0.1]] are mapped to [[TTML2]] features, and deprecated."

Yes, and the mapping should be as close as possible, if not identical.
The group however has some flexibility, e.g. in the case of
smpte:backgroundImage, where tt:image provides additional flexibility
that is probably desired in the long run, e.g. media type signaling.

On Mon, Nov 6, 2017 at 10:23 AM, Cyril Concolato <cconcolato@netflix.com> wrote:
> Note that this is what was agreed and recorded in this issue:
> https://github.com/w3c/imsc/issues/265
> A PR was merged in applying that: "extensions to [[TTML2]] that are
> specified in [[ttml-imsc1.0.1]] are mapped to [[TTML2]] features, and
> deprecated."
>
>
> On Sun, Nov 5, 2017 at 11:35 PM, Glenn Adams <glenn@skynav.com> wrote:
>>
>> 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) 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.
>>>
>>
>

Received on Monday, 6 November 2017 18:41:21 UTC