Re: Objections to TPAC resolutions on IMSC1.1

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.

> This is exactly what we have proposed.

In the case of itts:forcedDisplay, the changes proposed by Netflix are
drastic in syntax.

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

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

Received on Monday, 27 November 2017 23:35:43 UTC