Re: Objections to TPAC resolutions on IMSC1.1

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.

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 19:00:00 UTC