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

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.

Can an implementer intentionally make the two presentation processors different and still both be conformant? 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<mailto: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>.