Re: Objections to TPAC resolutions on IMSC1.1

On Tue, Nov 28, 2017 at 6:14 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Hi David,
>
> > I meant no modifications in behavior.
>
> Do you agree with moving the definitions (but not the namespace) from
> IMSC1 to TTML2?

Exactly as proposed in our objection.  Again, apologize if my word choice
confused that point.

> .


> > I did not mean bringing the IMSC and EBU-TT namespaces into TTML2.
>
> Do you object to bringing the IMSC namespaces in TTML2 and immediately
> deprecating them?
>
Yes.

>
> Best,
>
> -- Pierre
>
>
>
> On Mon, Nov 27, 2017 at 11:27 PM, David Ronca <dronca@netflix.com> wrote:
> >> David's exact words were:  "Netflix has proposed adding [IMSC1
> >> extension definitions] to TTML2 with no modifications."
> >
> > I meant no modifications in behavior.  I did not mean bringing the IMSC
> and
> > EBU-TT namespaces into TTML2.  Sorry for the confusion.
> >
> > On Mon, Nov 27, 2017 at 9:59 PM, Pierre-Anthony Lemieux <
> pal@sandflow.com>
> > wrote:
> >>
> >> Hi Glenn,
> >>
> >> David's exact words were:  "Netflix has proposed adding [IMSC1
> >> extension definitions] to TTML2 with no modifications."
> >>
> >> Do you agree with this proposal?
> >>
> >> Best,
> >>
> >> -- Pierre
> >>
> >> On Mon, Nov 27, 2017 at 9:56 PM, Glenn Adams <glenn@skynav.com> wrote:
> >> > I support the position laid out in Cyril's email, namely, TTML2 gets
> (in
> >> > existing TTML namespaces)
> >> >
> >> > ttp:activeArea
> >> > ttp:displayAspectRatio
> >> > tts:fillLineGap
> >> > tts:forcedDisplay
> >> > tts:linePadding
> >> > tts:multi[Row?]Align
> >> >
> >> > We ensure semantics are equivalent.
> >> >
> >> > I write tts:multi[Row?]Align because I would prefer tts:multiAlign
> since
> >> > the
> >> > term "Row" is semantically inaccurate; however, I would be willing to
> >> > concede this point if others insist.
> >> >
> >> > Note that, as Cyril has outlined, there are syntactic modifications,
> so
> >> > you
> >> > should probably stop repeating the mantra "no modifications".
> >> >
> >> >
> >> > On Mon, Nov 27, 2017 at 10:17 PM, Pierre-Anthony Lemieux
> >> > <pal@sandflow.com>
> >> > wrote:
> >> >>
> >> >> Hi Glenn,
> >> >>
> >> >> > > Netflix has proposed adding [IMSC1 extension definitions] to
> TTML2
> >> >> > > with no modifications
> >> >>
> >> >> Do you remain opposed to this approach?
> >> >>
> >> >> Best,
> >> >>
> >> >> -- Pierre
> >> >>
> >> >> On Mon, Nov 27, 2017 at 6:04 PM, David Ronca <dronca@netflix.com>
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > 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
> >> >> >> >>> >> >
> >> >> >> >>> >> >
> >> >> >> >>> >>
> >> >> >> >>> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>