Re: Objections to TPAC resolutions on IMSC1.1

> to discuss them on an email reflector, make only sense until a certain
point. I think we passed this point already.
I agree.  I think that we have reached the end of our ability to discuss on
the thread.  Netflix is working on a response to the technical concerns
that have been raised.  I think that this Thursday will be too soon to have
a meaningful conversation on the matter, and I propose that we push the
discussion out one week.

In the meantime, we would still like to hear any additional specific
technical concerns about our proposal.

Thanks,
David

On Tue, Nov 28, 2017 at 10:44 AM, Andreas Tai <tai@irt.de> wrote:

> Dear all,
>
>
>
> It seems obvious to me that we currently do not have any consensus on the
> discussed issue. I certainly do not agree to take established attributes,
> copy them to TTML and give them another namespace (e.g. the TTML Styling
> namespace). I have strong concerns about this procedure (which is one of
> the core aspects of the Netflix proposals). I commented this in the f2f
> meeting, in discussions and also in a wide review comment to TTML2.
>
>
>
> In general I agree with the comments by Pierre (especially with the points
> he raised in an Email yesterday evening/morning).
>
>
>
> The best way to discuss contentious issues are face 2 face meetings. The
> second best option are possibly telephone conferences. The third option, to
> discuss them on an email reflector, make only sense until a certain point.
> I think we passed this point already. I propose to continue the discussion
> in the  next call on Thursday (2017-11-30).
>
>
>
> Best regards,
>
>
>
> Andreas
>
>
>
> *Von:* David Ronca [mailto:dronca@netflix.com]
> *Gesendet:* Dienstag, 28. November 2017 18:15
> *An:* Pierre-Anthony Lemieux <pal@sandflow.com>
> *Cc:* Glenn Adams <glenn@skynav.com>; Nigel Megitt <nigel.megitt@bbc.co.uk>;
> TTWG <public-tt@w3.org>
> *Betreff:* Re: Objections to TPAC resolutions on IMSC1.1
>
>
>
>
>
>
>
> On Tue, Nov 28, 2017 at 8:32 AM, Pierre-Anthony Lemieux <pal@sandflow.com>
> wrote:
>
> Hi David,
>
> > Exactly as proposed in our objection.  Again, apologize if my word
> choice confused that point.
>
> Do you mean that Neflix' proposal (a) includes moving the definitions
> (but not the namespace) as-is, or (b) does not include moving the
> definitions (but not the namespace) as-is?
>
> I fear that we may be agreeing to terms that we interpret differently. ttp:activeArea
> would be restricted so that it is identical to ittp:activeArea.
> ittp:displayAspectRatio and ttp:displayAspectRatio appear to be equivalent.
> There are no equivalent options for ebutts:linePadding and
> ebutts:multiRowAlign. We propose to add them with no change in behavior. A
> logical copy/paste, if you will.
>
>
>
>
>
> >> Do you object to bringing the IMSC namespaces in TTML2 and immediately
> >> deprecating them?
> > Yes.
>
> So the IMSC namespaces would remain in IMSC, where they would be
> deprecated?
>
> Yes. We think that it is best to manage the IMSC issues in the IMSC spec.
>
>
> Thanks,
>
> -- Pierre
>
>
> On Tue, Nov 28, 2017 at 8:29 AM, David Ronca <dronca@netflix.com> wrote:
> >
> >
> > 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
> >> >> >> >> >>> >> >
> >> >> >> >> >>> >> >
> >> >> >> >> >>> >>
> >> >> >> >> >>> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
>
>