Re: Objections to TPAC resolutions on IMSC1.1

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
> >> >
> >> >
> >>
> >
>