Re: Objections to TPAC resolutions on IMSC1.1

On Mon, Nov 27, 2017 at 3:34 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi David,
>
> Thanks for sharing your thoughts.
>
> > Netflix has proposed adding them to TTML2 with no modifications
>
> At least participant indicated he would strongly object to this
> approach during the F2F.
>
Then we need to get the objections and specific concerns on the table so we
can have a discussion towards resolution.

>
> > This is exactly what we have proposed.
>
> In the case of itts:forcedDisplay, the changes proposed by Netflix are
> drastic in syntax.
>

Setting aside itts:forcedDisplay for the moment, what about
ittp:ActiveArea, ittp:aspectRatio, itts:fillLineGap, and
ebutts:multiRowAlign? These are not significant technical issues, assuming
that TTML2 is updated to support the equivalents.


> > We believe that it is better to define the equivalent tts:multiRowAlign
> in TTML2 rather than reference the EBU spec.
>
> Can you expand on why Netflix believes it is better? This may help
> folks change their position.
>
Because we will have a single upper spec, TTML2, for which we profile down
to a manageable subset for IMSC1.1.  That is a clean model.  Referring to
EBU-TT for a single feature seems unnecessary.

>
> Best,
>
> -- Pierre
>
> On Mon, Nov 27, 2017 at 3:24 PM, David Ronca <dronca@netflix.com> wrote:
> > Andreas Tai wrote:
> >> 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.
> >
> > The F2F established an IMSC1 baseline; a reference point for the next
> round
> > of discussion.  We have moved that forward with our objections, that were
> > accompanied with specific recommendations for the spec.  We are not back
> to
> > zero.  We now have a very specific set of issues and proposals that can
> be
> > discussed.  If we can work through our concerns, then we will have a
> strong
> > consensus.
> >
> > Pierre wrote:
> >> for any IMSC 1.0.1 extension adopted by TTML2, semantics and syntax
> >> should be modified as little as possible to avoid additional testing,
> >> training and unintended divergence
> >
> > This is exactly what we have proposed.  For the 4 IMSC features that are
> not
> > currently covered by TTML2, Netflix has proposed adding them to TTML2
> with
> > no modifications, and we have also volunteered to take on this work.
> >
> >> working with EBU to integrate features such as ebutts:multiRowAlign
> >> in TTML2 is an opportunity to coordinate with an important adopter of
> >> TTML, and reduce the potential for divergence.
> >
> > We believe that it is better to define the equivalent tts:multiRowAlign
> in
> > TTML2 rather than reference the EBU spec.
> >
> >> organizations that have recently adopted IMSC1 might lose confidence
> >> with the TTWG process if IMSC 1.1 deprecates all IMSC1 extensions and
> >> replaces them with substantially different alternatives
> > Netflix is such an organization, having recently adopted IMSC1.  I also
> > expect that we currently have the largest IMSC1 asset library.  We don't
> > take these changes lightly, but do so looking forward.  The real
> implication
> > of deprecated features is that at some point in the future, in some
> future
> > version of the spec, the deprecated features will no longer be supported
> in
> > that version of the spec.  IMSC1.01 processors will exist for as long as
> > there is a business case for them, and the translation from IMSC1 to an
> IMSC
> > 1.1 that is fully a TTML2 subset is trivial.  Lastly, feature
> deprecation is
> > a normal part of technology development, and certainly not new to W3C.
> >
> > On Mon, Nov 27, 2017 at 11:09 AM, Glenn Adams <glenn@skynav.com> wrote:
> >>
> >>
> >>
> >> On Mon, Nov 27, 2017 at 11:59 AM, Pierre-Anthony Lemieux
> >> <pal@sandflow.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> >> - IMSC1 has been adopted and deployed for interchange between
> multiple
> >>> >> parties, whereas TTML2 has not
> >>> > False.
> >>>
> >>> IMSC1 is a REC, which is referenced by multiple specifications,
> >>> including ISO/IEC 23000-19, SMPTE ST 2067-2, ATSC A/343, and DVB A174.
> >>>
> >>> IMSC 1.0.1 is a Candidate Recommendation.
> >>>
> >>> TTML2 is a Working Draft.
> >>>
> >>> > But this has been the plan all along, so such organizations are
> either
> >>> > misinformed or not following the work of the TTWG.
> >>>
> >>> For TTML2 to be successful, TTWG needs to satisfy user needs, not its
> >>> parochial interests.
> >>>
> >>> > Any resolution is subject to a period of at least two weeks to obtain
> >>> > confirmation from member organizations.
> >>>
> >>> I am not disputing the right for members to object to a resolution. I
> >>> am disputing the assertion that "I cannot recall any formal objection
> >>> to the synonym/alias proposal requested by Netflix". This assertion
> >>> cannot be true since there was no opportunity for formal objection at
> >>> TPAC since there was consensus on the resolution.
> >>
> >>
> >> I do not agree. There was not a consensus, since we explicitly noted at
> >> the time that an opportunity must be given members to consider the
> matter
> >> (and that they had 2 weeks to object).
> >>
> >> A consensus does not exist.
> >>
> >>>
> >>>
> >>> Best,
> >>>
> >>> -- Pierre
> >>>
> >>> On Mon, Nov 27, 2017 at 10:45 AM, Glenn Adams <glenn@skynav.com>
> wrote:
> >>> >
> >>> >
> >>> > On Mon, Nov 27, 2017 at 11:03 AM, Pierre-Anthony Lemieux
> >>> > <pal@sandflow.com>
> >>> > wrote:
> >>> >>
> >>> >> Hi Nigel et al.,
> >>> >>
> >>> >> I do not believe it is possible to fully capture the interactive and
> >>> >> in-person discussions that led to the consensus resolution adopted
> at
> >>> >> TPAC. Nevertheless, based on my notes, below is additional
> information
> >>> >> that was shared by at least one member (not necessarily me) during
> >>> >> these discussions:
> >>> >>
> >>> >> - for any IMSC 1.0.1 extension adopted by TTML2, semantics and
> syntax
> >>> >> should be modified as little as possible to avoid additional
> testing,
> >>> >> training and unintended divergence
> >>> >
> >>> >
> >>> > We are not considering the adoption of non-TTML features in TTML2. We
> >>> > are
> >>> > defining core functionality that we have been discussing for some
> time
> >>> > now,
> >>> > before the creation of either IMSC1 or IMSC1.0.1. Nevertheless, there
> >>> > is a
> >>> > general agreement that common features should have similar semantics.
> >>> >
> >>> >>
> >>> >>
> >>> >> - given the objective of aligning TTML and CSS, TTML2 can delay
> >>> >> adoption of features in its namespace for which there is no CSS
> >>> >> equivalent but for which industry extensions exist, e.g.
> >>> >> ebutts:linePadding,
> >>> >
> >>> >
> >>> > Given that such an addition to CSS would require years to obtain in a
> >>> > REC,
> >>> > it is entirely impractical to use this rationale with TTML2 (and
> >>> > probably
> >>> > TTML3).
> >>> >
> >>> >>
> >>> >>
> >>> >> - organizations that have recently adopted IMSC1 might lose
> confidence
> >>> >> with the TTWG process if IMSC 1.1 deprecates all IMSC1 extensions
> and
> >>> >> replaces them with substantially different alternatives
> >>> >
> >>> >
> >>> > But this has been the plan all along, so such organizations are
> either
> >>> > misinformed or not following the work of the TTWG.
> >>> >
> >>> >>
> >>> >>
> >>> >> - IMSC1 has been adopted and deployed for interchange between
> multiple
> >>> >> parties, whereas TTML2 has not
> >>> >
> >>> >
> >>> > False.
> >>> >
> >>> >>
> >>> >>
> >>> >> - working with EBU to integrate features such as
> ebutts:multiRowAlign
> >>> >> in TTML2 is an opportunity to coordinate with an important adopter
> of
> >>> >> TTML, and reduce the potential for divergence.
> >>> >
> >>> >
> >>> > Adopting non-TTML vocabulary is contrary to the original requirements
> >>> > documented by TTAF1 for use in TTML.
> >>> >
> >>> >>
> >>> >>
> >>> >> > Given that I cannot recall any formal objection to the
> synonym/alias
> >>> >> > proposal requested by Netflix,
> >>> >>
> >>> >> There was no opportunity to raise formal objections during the TPAC
> >>> >> meeting since the resolution was adopted by consensus.
> >>> >
> >>> >
> >>> > Any resolution is subject to a period of at least two weeks to obtain
> >>> > confirmation from member organizations.
> >>> >
> >>> >>
> >>> >>
> >>> >> Best,
> >>> >>
> >>> >> -- Pierre
> >>> >>
> >>> >> On Fri, Nov 24, 2017 at 9:13 AM, Nigel Megitt <
> nigel.megitt@bbc.co.uk>
> >>> >> wrote:
> >>> >> > 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) 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>
> >>> >> > Date: Wednesday, 15 November 2017 at 18:55
> >>> >> > To: TTWG <public-tt@w3.org>
> >>> >> > Subject: Objections to TPAC resolutions on IMSC1.1
> >>> >> > Resent-From: <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
> >>> >> >
> >>> >> >
> >>> >>
> >>> >
> >>
> >>
> >
>