Re: [w3c/ttml2] processor backwards compatibility (#458)

On Wed, Oct 11, 2017 at 12:40 PM, Michael Dolan <mike@dolan.tv> wrote:

> Glenn and all,
>
>
>
> I thought we all agreed in the meeting that a TTML2 presentation processor
> is intended to be able to render a TTML1 document the same as a TTML1
> presentation processor would. That is, there are not in fact any semantic
> differences for TTML1 features included in TTML2.
>

Perhaps I expressed myself poorly in the meeting. What I intended to say
was that a random TTML presentation processor that claims support for TTML2
may, in addition, claim support for TTML1, and, therefore, may decide which
set of semantic rules to use when performing presentation processing. It
may choose TTML2 rules or it may choose TTML1 rules.

We have not defined TTML2 as a delta on top of TTML1, we have defined TTML2
as a new language from whole cloth, one that just happens to make use of
many of the same constructs as TTML1, and, indeed, includes the three
profiles defined in TTML1 as well as adopting the same feature designators
from TTML1 as a starting point.

Now, in theory, given a specific document, this means that a presentation
processor may produce one rendering when treating that document as a TTML2
document and another rendering when treating it as a TTML1 document.

IMO, the pertinent question is, if you have a document that uses only TTML1
features, then COULD such a processor produce a different rendering if it
treats it as a TTML2 document instead of a TTML1 document? I can envision a
couple of possible answers here:

   - it MAY (produce a different rendering)
   - it SHOULD NOT (produce a different rendering)
   - it MUST NOT (produce a different rendering)

I suspect that you want the answer to be MUST NOT, but I would prefer
something between MAY and SHOULD NOT. Absent performing a full detailed
review of every technical change between TTML1 and TTML2 specs, I would
give a provisional, operational answer of:

When the specified TTML2 processing explicitly diverges from TTML1
processing, it MAY produce a different rendering; otherwise, it SHOULD NOT
produce a different rendering, where, by "different rendering", we mean
different modulo any variation that may result from

   - use of different line layout implementations
   - use of different font rasterizer implementations
   - use of different physical fonts
   - use of different root container region aspect ratio, resolution, or
   coordinate space
   - [possibly more axes of variation admissible here]

Now, a useful question to consider is whether or not reuse of the same set
of feature designators from TTML1 in TTML2 means that, when referring to
those features when processing a document as a TTML2 document, rendering
differences (beyond those cited above) are permitted or even desired. I can
see the potential for different approaches here depending on whether

   - the document uses no TTML2 feature, or
   - the document explicitly marks itself as a TTML2 document or the
   processor infers this from other information, e.g., by evaluation of the
   features used in the document, by a command line option from the user, etc.

Here, I would probably give the following guidance to an implementer

   - if the document cannot be proven to use a TTML2 feature, then, absent
   explicit user control to the contrary, then, if the processor supports the
   presentation of TTML1 documents, it SHOULD process such a document as a
   TTML1 document; i.e., it (the processor) should behave as a TTML1 processor.

and, by "user", I here mean whatever entity is controlling the processor,
be it human or an enclosing software environment.


>
> Can an implementer intentionally make the two presentation processors
> different and still both be conformant?
>

At present, I think we do not require a TTML2 processor to also be a TTML1
processor, which means that it may and need not process an arbitrary TTML
document the same as a TTML1 processor would. Indeed, I suspect there are
variations in behavior (which we can confirm by more study of the
specification texts), that we intended, and didn't happen by accident. It
is also possible that we have permitted variations by accident where more
consideration might unify behavior..

I also want to note that I have defined a number of explicitly version 2
feature designators, presently

   - animation-version-2
   - bidi-version-2
   - displayAlign-version-2
   - padding-version-2
   - textAlign-version-2

I did this because it was my intention that where a feature was enhanced or
otherwise constrained differently in version 2, then there should be a
distinct feature designator to cover it, which presumes I intended that
feature designators inherited from TTML1 should not be substantially
altered. On the other hand, we have defined or changed certain macroscopic
behavior in TTML2, such as:

   - profile selection and semantics
   - root container region semantics
   - style inheritance semantics
   - timing semantics
   - [more?]

It might be useful to carefully consider these changes to evaluate possible
impact on the meaning of feature designators inherited from TTML1.


> Yes, just as two implementers of TTML1 can; or even the same
> implementation on different underlying platforms. But the point is that it
> is possible, and in fact expected, all other things (like platforms) being
> equal for there to be the same presentation.
>
>
>
> I offered to try and draft language in section 3.4 towards capturing the
> above notion.
>
>
>
> I guess we’ll have to revisit this discussion tomorrow and see if we can’t
> capture in writing what it is we all think we agreed to on this topic...
>
>
>
>                 Mike
>
>
>
> *From:* Glenn Adams [mailto:notifications@github.com]
> *Sent:* Wednesday, October 11, 2017 11:22 AM
> *To:* w3c/ttml2 <ttml2@noreply.github.com>
> *Cc:* Michael A Dolan <md.1@newtbt.com>; Author <author@noreply.github.com
> >
> *Subject:* Re: [w3c/ttml2] processor backwards compatibility (#458)
>
>
>
> On Wed, Oct 11, 2017 at 11:55 AM, Michael A Dolan <
> notifications@github.com>
> wrote:
>
> > This is a proposal based on the discussion from the 5-Oct WG meeting on
> > this topic. See also: w3c/ttml2#442
> > <https://github.com/w3c/ttml2/issues/442> and w3c/imsc1#258
> > <https://github.com/w3c/imsc/issues/258>.
> >
> > Background: several of us are concerned about backwards compatibility of
> > TTML1/TTML2 presentation processors, especially in the context of
> > IMSCvNEXT. Specifically, the concern is that a conformant IMSC1 document
> > (optionally including TTML2 features such as tts:disparity) creates the
> > same presentation out of an IMSCvNEXT presentation processor as an IMSC1
> > presentation processor. And, not because it might be the same author of
> the
> > implementation. This potentially could be solved with conformance
> > statements in IMSCvNEXT except to the extent it references TTML2 (rather
> > than TTML1) when TTML2 itself is potentially conflicting (at least for
> > documents it determines to be version=2) and not subject to such a
> > constraint.
> >
> > Examining TTML2…
> >
> > Re section 3.4:
> >
> > 3.4.2 …A conforming TTML2 processor should be able to process a TTML1
> > content document instance; however, it may emit warnings if it encounters
> > deprecated features.
> >
> > Why is the above a “should” and not a “shall”? That is, when would it be
> > permitted/desirable for it to deviate?
> >
> Two reasons: (1) this section is non-normative; (2) it should be possible
> to create a strictly TTML2 only processor (at the choice of the
> implementer).
>
> > There is no specific statement about presentation processor backwards
> > compatibility. The fact that it is also a “processor” is inadequate since
> > TTML2 is generally silent about presentation details across
> implementations
> > as well as between TTML1 and TTML2, except for an informative note
> listing
> > example permitted variations across implementations, inferring there are
> > more that go unstated:
> >
> > 3.2.3 "…Note:
> > Two conforming presentation processors are not required to produce the
> > same presentation when processing the same conforming document. For
> > example, different presentation processors may use different fonts,
> > different font rasterizers, different line break algorithms, as well as
> > different implementations of behavior not prescribed by this
> specification."
> >
> > Although this is an accurate general representation of the potential
> > variations between implementations, the silence of the substantive
> > statement that is desirable: “all other things being equal, the
> > presentation shall be deterministic and consistent across
> implementations”.
> > But this is testable without an exhaustive list of permitted
> > implementation-dependent variations.
> >
> Deterministic rendering is impossible across implementations. This is not
> and never has been a requirement for TTML1 or TTML2.
>
> > Whether we alter the above conformance provisions or not, I think I am
> > leaning to make a broad scope statement about the intent of the TTML2
> > specification itself of the form: “The provisions of this specification
> > covering TTML1 features are intended to be identical to those same
> > provisions in TTML1. That is, any deviation is unintended.”
> >
> I would certainly disagree with this notion. There are a variety of
> intended deviations. The reason we agreed long ago to call it TTML2 instead
> of 1.1 is because we wanted the flexibility to NOT be backwards compatible.
>
> This, for example, is one reason we added 3 new TTML2 specific profiles to
> the existing 3 TTML1 profiles. If an implementer wants to create a
> processor that effectively has a switch saying whether to follow TTML2 or
> TTML1 processing semantics, then they are free to do so. It is up to the
> author to effectively mark a document as to which version they wish to have
> followed, e.g., by specifying tts:version='1' or not specifying
> tts:version, or by telling the processor which regime to use, etc.
>
> The best we can do is give guidance to implementers and authors regarding
> how to process or create documents so there is a reasonable likelihood they
> will get what they want.
>
> > —
> > You are receiving this because you are subscribed to this thread.
> > Reply to this email directly, view it on GitHub
> > <https://github.com/w3c/ttml2/issues/458>, or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/AAXCb0Ko3uJahpXpuR7-
> vfGO1isfcPDGks5srQEggaJpZM4P14VA>
> > .
> >
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/ttml2/issues/458#issuecomment-335902429>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AEUs9Ky8BnOnqO64cUfhisMIUKrpPcyoks5srQdDgaJpZM4P14VA>
> .
>