Re: Objections to TPAC resolutions on IMSC1.1

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:07:45 UTC