Re: Objections to TPAC resolutions on IMSC1.1

If by "moving into TTML2" you mean "define in TTML2 using the same prefix
and value as used in IMSC1", then Skynav objects for the following reasons:

   - this would create two normative definitions of the same namespace, one
   in IMSC1 and another in TTML2;
   - the value of the namespace as defined in IMSC1 is
   http://www.w3.org/ns/ttml/profile/imsc1#parameter, which claims to be a
   profile of TTML, and which would end up having TTML2 define a part of a
   profile of itself, which is semantically inconsistent;
   - the cost of cognitive overhead (of keeping track of subtle naming
   differences) on the part of authors and quality assurance is very high
   while the benefit of syntactic interoperability for what would essentially
   be two special case uses (ittp:activeArea and ittp:aspectRatio) is very low
   (particularly since syntactic interoperability is not maintained elsewhere,
   e.g., smpte:backgroundImage vs tt:image);
   - adoption of the ittp namespace in TTML2 would presumably entail
   adopting ittp:aspectRatio as well, which would introduce a semantic
   ambiguity due to the need to more explicitly distinguish between three
   types of aspect ratios in TTML2 (DAR,SAR,PAR);
   - multiple existing, tested, and production implementations of TTML2 and
   its tool chains would require multiple changes and special case coding that
   is not presently required;
   - multiple existing production and test content that adheres to the
   TTML2 would require multiple changes
   - multiple requirements that form the design basis for TTML1 and TTML2,
   specifically, the requirement to maintain an identifiable and consistent *TT
   Core Vocabulary* [1] would be subject to instabilities that do not exist
   at present, and may very well result (eventually) in the dissolution of TT
   Core Vocabulary into unmanageable and possibly overlapping subsets;
   - adopting what is effectively non-core, extension vocabulary outside
   the core vocabulary sets a dangerous precedent that will reduce the
   consistency, implementability, and authorability afforded by TTML as
   presently organized;

[1] https://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/

On Tue, Nov 28, 2017 at 4:51 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

> Would you (or any other member) object to moving the definition of the
> ittp namespace into TTML2?
>
>
> From: Glenn Adams <glenn@skynav.com>
> Date: Tuesday, 28 November 2017 at 05:56
> To: Pierre-Anthony Lemieux <pal@sandflow.com>
> Cc: Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>, David
> Ronca <dronca@netflix.com>
> Subject: Re: Objections to TPAC resolutions on IMSC1.1
>
> 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
>> >> >>> >> >
>> >> >>> >> >
>> >> >>> >>
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >
>> >
>>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>