[ttml2] processor backwards compatibility

mikedo has just created a new issue for https://github.com/w3c/ttml2:

== processor backwards compatibility ==
This is a proposal based on the discussion from the 5-Oct WG meeting on this topic. See also: w3c/ttml2#442 and w3c/imsc1#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?

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.

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.”


Please view or discuss this issue at https://github.com/w3c/ttml2/issues/458 using your GitHub account

Received on Wednesday, 11 October 2017 17:55:50 UTC