Re: Objections to TPAC resolutions on IMSC1.1

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 14:21:24 UTC