Re: Objections to TPAC resolutions on IMSC1.1

Hi Nigel,

Deprecation means that the feature will be entirely removed in the
future, so authors *should not* be used the feature going forward --
this is the common definition of "deprecated" and Netflix's objective
as I understand it.

Assuming this is the objective, an author should use the TTML2 feature
and not the IMSC1 feature, unless he/she knows it is targeting an
IMSC1-only processor, in which case he/she would need to use the IMSC1
feature.

Perhaps you mean something else by "deprecation"?

Allowing both new and deprecated feature requires incremental logic in
processors [1], and is additionally tricky/surprising because of the
complex TTML inheritance rules. For instance, per the Netflix
proposal, a deprecated styling attribute specified on a <p> is
overridden by a new styling attribute positioned on a referenced
style, even though inline styling typically overrides referential
styling.

[1] https://github.com/w3c/imsc-vnext-reqs/issues/14#issuecomment-347083811

> I had assumed that nobody would want to force this situation on document authors.

I would rather not deprecate any feature in use :), but here we are.

Best,

-- Pierre

On Tue, Nov 28, 2017 at 6:20 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:
> Hi Pierre,
>
> If the presence of both old and new features in a single document is
> prohibited then document authors targeting both old and new processors are
> forced to create a document for each, i.e. two documents where one was
> needed before. I had assumed that nobody would want to force this
> situation on document authors.
>
> Kind regards,
>
> Nigel
>
>
> On 28/11/2017, 14:06, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
>
>>Hi Nigel,
>>
>>> Precedence rules are an unavoidable consequence of deprecation in favour
>>> of a new better way to achieve a similar presentation outcome.
>>
>>Precedence rules are not necessary if the presence of both old and new
>>features in a single document is prohibited.
>>
>>Best,
>>
>>-- Pierre
>>
>>On Tue, Nov 28, 2017 at 3:50 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>>wrote:
>>>> IMSC 1.1 should allow only one version of each feature in a given
>>> document: precedence rules adds complexity to an already complex
>>> specification -- see [1]. Recall that some of these attributes are
>>> inheritable.
>>>
>>> Precedence rules are an unavoidable consequence of deprecation in favour
>>> of a new better way to achieve a similar presentation outcome. The
>>> alternatives are: never change any feature or force change in features
>>>by
>>> going directly to prohibition of old features when introducing new ones.
>>> Both those alternatives are worse than specifying precedence rules.
>>>
>>>
>>>> hopefully TTWG can be more responsive and
>>> welcoming to external requests in the future.
>>>
>>> This is an argument in favour of splitting out styling vocabulary in
>>> particular into separate specification(s), so that additional styling
>>> features can be introduced independently of the base specification
>>> version, in an appropriate namespace, with minimal dependencies.
>>>
>>>
>>> Nigel
>>>
>>>
>>> On 28/11/2017, 06:15, "Pierre-Anthony Lemieux" <pal@sandflow.com> wrote:
>>>
>>>>Hi Cyril,
>>>>
>>>>Thanks for the details. Below is my feedback.
>>>>
>>>>> c) for forcedDisplay:
>>>>> - related semantics, with additional ability
>>>>
>>>>The Netflix proposal introduces not additional capabilities within the
>>>>scope of IMSC 1.1.
>>>>
>>>>The Netflix proposal introduces a completely different syntax and
>>>>document construction [1].
>>>>
>>>>[1] https://github.com/w3c/ttml2/issues/482#issuecomment-342324353
>>>>
>>>>It is unreasonable to replace a market-tested syntax
>>>>(itts:forcedDisplay) that conveys clear authorial intent, with one
>>>>that has not been deployed in practice and does not bring meaningful
>>>>improvements within the scope of IMSC 1.1.
>>>>
>>>>> we believe only 2 additional tests per features are needed: one with
>>>>>the TTML2 syntax, one with both.
>>>>> Do you disagree?
>>>>
>>>>IMSC 1.1 should allow only one version of each feature in a given
>>>>document: precedence rules adds complexity to an already complex
>>>>specification -- see [1]. Recall that some of these attributes are
>>>>inheritable.
>>>>
>>>>>  I think it is very confusing to have in the same document styling or
>>>>>parameter attributes in different and yet
>>>>> very similar namespaces: 'ittp' vs. 'ttp', 'itts' vs. 'tts'. How many
>>>>>documents will contain mistakes
>>>>> (missing the extra 'i')?
>>>>
>>>>Yes. It is unfortunate -- hopefully TTWG can be more responsive and
>>>>welcoming to external requests in the future.
>>>>
>>>>The group can consider supporting both namespaces/names in TTML2, and
>>>>deprecating the legacy ones.
>>>>
>>>>> For activeArea, aspectRatio or forceDisplay, we do have existing text
>>>>>in TTML2.
>>>>> Do you see any divergence? text that cannot be aligned?
>>>>
>>>>I see little technical risk with the current activeArea and
>>>>displayAspectRatio text in TTML2, although additional time will be
>>>>necessary for the group to convince itself that it is the case if the
>>>>IMSC1 text is not used as-is -- the TTML2 editor stated that
>>>>equivalence with IMSC1 was not a priority.
>>>>
>>>>> I don't see how this makes a difference one way or the other, plus it
>>>>>is likely
>>>>> that other CSS-related deprecation will happen.
>>>>
>>>>The argument, as I understood it, is to minimize churn: IMSC 1.1 would
>>>>adopt a syntax that is likely to be deprecated, when it has an
>>>>existing syntax that meets functional needs.
>>>>
>>>>>  But what are the risks of divergence?
>>>>
>>>>The risk is that other organizations ignore IMSC 1.1 and continue
>>>>evolving their own profiles, jeopardizing the very objective of this
>>>>group.
>>>>
>>>>> I don't think we should speculate on what other organizations might
>>>>>think.
>>>>
>>>>SMPTE explicitly stated [2] that "in light of mandatory regulatory
>>>>requirements, it is critical that
>>>>future versions IMSC (and thus TTML2) be designed to minimize changes
>>>>to existing IMSC1 processors."
>>>>
>>>>DVB explicitly requested itts:fillLineGap and itts:activeArea [3], so
>>>>presumably it cares about their outcome.
>>>>
>>>>EBU originally defined ebutts:linePadding and ebutts:multiRowAlign, so
>>>>I would think it is a stakeholder.
>>>>
>>>>[2]
>>>>https://lists.w3.org/Archives/Member/member-tt/2017Oct/att-0000/SMPTE-to
>>>>-W
>>>>3C-ttml2-20170929.pdf
>>>>[3]
>>>>https://lists.w3.org/Archives/Member/member-tt/2017Apr/att-0004/liaison-
>>>>re
>>>>ply-to-W3C-about-IMSC101.pdf
>>>>
>>>>My point is that these organizations are presumably happy with the
>>>>current state of things. Netflix argues that TTWG should ask them to
>>>>change. Even if the reasons for the changes are good, but it behooves
>>>>TTWG to minimize these changes and weigh the pros/cons carefully.
>>>>
>>>>Best,
>>>>
>>>>-- Pierre
>>>>
>>>>On Mon, Nov 27, 2017 at 6:03 PM, Cyril Concolato
>>>><cconcolato@netflix.com>
>>>>wrote:
>>>>> Pierre,
>>>>>
>>>>> On Mon, Nov 27, 2017 at 10:03 AM, Pierre-Anthony Lemieux
>>>>><pal@sandflow.com>
>>>>> 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
>>>>>
>>>>> Let's be more concrete here. We are proposing:
>>>>>
>>>>>
>>>>> a) for activeArea:
>>>>>
>>>>> - no semantic change compared to IMSC1.0.1,
>>>>>
>>>>> - an IMSC1.0.1 compatible-value syntax change,
>>>>>
>>>>> - no attribute name change
>>>>>
>>>>> - the use of the same namespace as other TTML parameters
>>>>>
>>>>>
>>>>> b) for aspectRatio:
>>>>>
>>>>> - use of semantics based on the clarifications in TTML2
>>>>>
>>>>> - no value syntax change compared to IMSC1.0.1
>>>>>
>>>>> - attribute name change: from aspectRatio to displayAspectRatio
>>>>>
>>>>> - the use of the same namespace as other TTML parameters
>>>>>
>>>>>
>>>>> c) for forcedDisplay:
>>>>>
>>>>> - related semantics, with additional ability
>>>>>
>>>>> - different syntax
>>>>>
>>>>> - the use of the same namespace as other TTML constructs
>>>>>
>>>>>
>>>>> d) for fillLineGap, linePadding, multiRowAlign:
>>>>>
>>>>> - same semantics
>>>>>
>>>>> - same value syntax
>>>>>
>>>>> - same attribute name
>>>>>
>>>>> - the use of the same namespace as other TTML styling attributes
>>>>>
>>>>>
>>>>> Regarding the attribute names, the differences are only for
>>>>>forcedDisplay
>>>>> and aspectRatio. We could imagine changing displayAspectRatio to
>>>>>aspectRatio
>>>>> in TTML2 if it helps. The name change is justified I think regarding
>>>>> forceDisplay as condition is broader.
>>>>>
>>>>> Regarding namespace prefixes, you mentioned training, testing ... I
>>>>>think it
>>>>> is very confusing to have in the same document styling or parameter
>>>>> attributes in different and yet very similar namespaces: 'ittp' vs.
>>>>>'ttp',
>>>>> 'itts' vs. 'tts'. How many documents will contain mistakes (missing
>>>>>the
>>>>> extra 'i')? How many hours of training are you willing to give to
>>>>>explain
>>>>> that sometimes you have to use an 'i' and sometimes not, and that they
>>>>>exist
>>>>> because of historical/process reasons? How many dev efforts will be
>>>>>spent on
>>>>> finding related bugs in software?
>>>>>
>>>>> Regarding testing, I mentioned that we believe only 2 additional tests
>>>>>per
>>>>> features are needed: one with the TTML2 syntax, one with both. Do you
>>>>> disagree?
>>>>>
>>>>> Regarding divergence, I agree we should avoid it. But what are the
>>>>>risks of
>>>>> divergence?
>>>>> For activeArea, aspectRatio or forceDisplay, we do have existing text
>>>>>in
>>>>> TTML2. Do you see any divergence? text that cannot be aligned?
>>>>> For fillLineGap, given that we are not proposing any semantic change
>>>>>and
>>>>> that IMSC1.0.1 text is under W3C copyright, so we should be able to
>>>>> copy/paste it as is in TTML2. I don't see any risk of divergence.
>>>>> For linePadding and multiRowAlign, the divergence risk exists if W3C
>>>>>would
>>>>> not be allowed to copy/paste EBU's text as is, or almost.
>>>>>
>>>>>>
>>>>>>
>>>>>> - 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,
>>>>>
>>>>> Let's assume that in 2 years from now, browsers have support for a CSS
>>>>> linePadding property.
>>>>> It might be the same exact syntax and semantics as ebutts:linePadding
>>>>>(I
>>>>> doubt, e.g. because of the line wrap issue) in which case dropping the
>>>>> ebutts namespace now in IMSC1.1 allows us in the future IMSC1.2 to
>>>>>have
>>>>>the
>>>>> right to redefine it in terms of CSS, without requiring any change of
>>>>> syntax.
>>>>> It might have a different syntax and semantics, in which case IMSC1.2
>>>>>will
>>>>> deprecate ebutts:linePadding (if kept in ebutts namespace) or
>>>>> tts:linePadding (if used in TTML namespace) in favor of
>>>>> tts:cssDefinedLinePadding with a mapping.
>>>>> I don't see how this makes a difference one way or the other, plus it
>>>>>is
>>>>> likely that other CSS-related deprecation will happen.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> - 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
>>>>>
>>>>>
>>>>> Organizations are probably concerned first about timeline and delivery
>>>>>of
>>>>> specifications. Organizations might also prefer a clean, centralized
>>>>> specification with fewer namespaces (and fewer risk of errors) and a
>>>>>clear
>>>>> deprecation model. I don't think we should speculate on what other
>>>>> organizations might think. We should first concentrate on delivering
>>>>>on
>>>>>time
>>>>> and communicate at that time on the changes and rationale.
>>>>>
>>>>> Best,
>>>>> Cyril
>>>>>
>>>>>>
>>>>>> - IMSC1 has been adopted and deployed for interchange between
>>>>>>multiple
>>>>>> parties, whereas TTML2 has not
>>>>>>
>>>>>> - 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.
>>>>>>
>>>>>> > 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.
>>>>>>
>>>>>> 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.
>>> -----------------------------
>

Received on Tuesday, 28 November 2017 18:28:22 UTC