Re: Objections to TPAC resolutions on IMSC1.1

> 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 11:51:08 UTC