AW: Objections to TPAC resolutions on IMSC1.1

Dear Nigel, all,

 

First I want to emphasize the importance of f2f meetings. Resolutions we
found in these meetings are hard to get offline or in telco's.

 

We found resolutions in the f2f meeting on 2017-11-09 and 2017-11-10 based
on the consensus principle. These resolutions represent already a
compromise. With the formal objections we are now back to zero and need now
come again to resolution by the consensus principle in our next meetings.
Because we do not have such new resolutions, there is nothing to object to
yet. 

 

>From the documented discussion in the f2f you can see that the latest
proposals do not address major concerns raised at the f2f. 

 

I also have a different re-collection on the discussions as reflected in
your summary and interpretations. But it is difficult to summarize the
position of all group members and it may be best to confirm your view in a
groups meeting.

 

Best regards,

 

Andreas 

    

 

Von: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk] 
Gesendet: Freitag, 24. November 2017 18:13
An: TTWG <public-tt@w3.org>
Betreff: Re: Objections to TPAC resolutions on IMSC1.1

 

All,

 

This is a situation in which we do not currently seem to have consensus. It
appears that two camps exist, with mutually incompatible visions for how the
IMSC 1.1 and TTML2 specifications should incorporate some features. 

 

Be reminded that W3C consensus means we have to find a solution that
everyone can accept, even though it might not be the one that everyone
thinks is the best alternative.

 

To summarise the technical issue as I understand it:

 

* IMSC 1.0.1 includes extensions not in TTML1, defined using syntax in
namespaces not defined by TTML1

* We want to support the requirements met by those extensions in IMSC 1.1

* We want to support the requirements met by those extensions in TTML2

* We want IMSC 1.1 to be a subset of TTML2 - there are varying degrees of
strength about this amongst the group members, i.e. some want all non-TTML2
features to be deprecated, others are happy to continue with non-deprecated
extensions.

* It is important to some (maybe all) members that IMSC 1.1 processors be
able to process IMSC 1.0.1 documents

* We discussed but rejected creating an IMSC 2 that is a pure subset of
TTML2 and does not natively support IMSC 1.0.1

* It is important to some (but not all) members that TTML2 defines all
features in its own namespace

* The idea of adopting extensions into TTML2 and making them features with
no change to their existing namespace was discussed but not adopted. There
was a formal objection on the grounds that all TTML features must be defined
in the TTML namespace. There was also a process point that we would need to
seek permission from EBU for inclusion of EBU namespace extensions.

 

During the TPAC 2017 face to face meeting (minutes
<https://www.w3.org/2017/11/09-tt-minutes.html> ) we resolved one of two
approaches for each feature:

 

1. In TTML2: include a new feature in a TTML namespace. In IMSC 1.1:
deprecate the IMSC 1.0.1 extension AND include the TTML2 feature AND provide
a mapping from the deprecated extension to the new feature.

2. In TTML2: do not include a new feature. In IMSC 1.1: include the IMSC
1.0.1 extension.

 

Netflix has objected to some of those resolutions within the WG's review
period defined under the Decision Policy in the Charter. I have received no
other objections within that period (which expires at the end of the working
day today, California time). I have updated and where necessary reopened the
relevant GitHub issues indicating the objection.

 

* The idea of synonyms or aliases was raised (disclosure: by me), discussed
but not adopted, i.e. TTML namespace syntax for features where each feature
is a functional equivalent or superset of an IMSC 1.0.1 extension, and both
may be supported in IMSC 1.1 with a mapping to the canonical TTML2
equivalent. The synonym may additionally be noted informatively in TTML2.
The key negative point was that it would encourage the use of both sets of
syntax in many documents with no clear end point to the practice and no
practical benefit. However I cannot recall any formal objection, nor find
one in the minutes. 

 

The Netflix objection essentially requests that this latter model be
adopted, whilst deprecating the IMSC 1.0.1 extensions.

 

Given that I cannot recall any formal objection to the synonym/alias
proposal requested by Netflix, I'd like to check if we actually have
consensus to adopt it already, i.e. if despite it not being everyone's
favourite option, it is something that everyone can nevertheless live with.

 

Does anyone object to any of the Netflix proposals? If so, please be
specific about the nature of the objection. This will help us to construct
new proposals.

 

This topic will be on the agenda for next week's call (November 30th), but
if possible I would like to have a sense of the conclusion or any as yet
unraised concerns before the meeting. If anyone would like a call with me or
others to discuss this informally ahead of the meeting, I am happy to
support that, and can be available on Monday 1600-1700 UK time, Tuesday
1630-1730 UK time or Wednesday 1500-1730 UK time.

 

Nigel

 

 

From: Cyril Concolato <cconcolato@netflix.com
<mailto:cconcolato@netflix.com> >
Date: Wednesday, 15 November 2017 at 18:55
To: TTWG <public-tt@w3.org <mailto:public-tt@w3.org> >
Subject: Objections to TPAC resolutions on IMSC1.1
Resent-From: <public-tt@w3.org <mailto:public-tt@w3.org> >
Resent-Date: Wednesday, 15 November 2017 at 18:56

 

Dear TTWG experts,





Following TPAC, Netflix would like to inform the group that it is not
satisfied with some of the resolutions regarding IMSC1.1 and objects to
them. Netflix thinks that two important goals must be satisfied in defining
TTML2 and IMSC1.1:

- IMSC1.1 must be a strict-subset of TTML2, aside from deprecated features.
We believe it is bad practice for W3C to define two TTML-based standards, at
the same time, which are not compatible with each other. 

- TTML2 must limit its normative references to Web Platform standards. We
believe it is bad practice to have to compile multiple sources of
information outside of the Web Platform to implement the standard.

 

Netflix asks for the following actions:

a) Marking ittp:activeArea deprecated in IMSC1.1, using a reference to
IMSC1.0.1 and no definition in IMSC1.1, in favor of ttp:activeArea,
restricted to using two-component values such that ttp:activeArea can be
used to do no more than IMSC1.0.1 ittp:activeArea.

b) Marking ittp:aspectRatio deprecated in IMSC1.1, using a reference to
IMSC1.0.1 and no definition in IMSC1.1, in favor of ttp:displayAspectRatio.
There does not seem to be a need for restricting ttp:displayAspectRatio.

c) Marking itts:forcedDisplay deprecated in IMSC1.1, using a reference to
IMSC1.0.1 and no definition in IMSC1.1, in favor of a combination of
'condition' and 'tts:visibility', with the appropriate restrictions on
condition such that it remains simple to implement, while at the same time
offering more flexibility than forcedDisplay.

d) Adding the definitions of itts:fillLineGap, ebutts:linePadding and
ebutts:multiRowAlign to TTML2, with no change to the semantics, but in the
TTML namespace; and marking the itts/ebutts version as deprecated in
IMSC1.1.

e) IMSC1.1 should indicate that when TTML2 features are used in the same
document at the same time as their non-TTML2 equivalent and deprecated
features, the TTML2 features prevail. This insures that future versions of
IMSC can effectively remove the features marked as deprecated.

 

Netflix believes that this approach provides clearly designed, forward
looking standards, reducing the complexity of the TTML ecosystem.

 

Netflix is aware that this requires an effort of the TTML community as
follows:

- IMSC1.0.1 renderers do not need to be updated, unless they need to support
Japanese features. The changes required by the proposed dual syntax and
deprecation model are minor compared to them, as they can be implemented
using aliases or simple transforms.

- Authoring tools already supporting IMSC1.0.1 do not need to migrate to the
TTML2 syntax, as renderers are required to support both. They only need to
be updated to support Japanese features. They would need to be updated when
the deprecated features are removed in a future version.

- Specs need to be updated. Netflix is willing to update the TTML2 and
IMSC1.1 specs as proposed above.

- Test suites need to be updated. For each of the features above, 2
additional tests need to be provided: one with the TTML2 flavor and without
the IMSC1.0.1 flavor; and one with both (testing the override model).
Netflix is willing to contribute these tests.





We suggest adding these points to the next meeting's agenda.





Best regards,

Cyril