Replacing references from TTML1 to TTML2

[palemieux]

From Mike Dolan:

Given the W3C practice of copying provisions in version N rather than normatively referencing version N-1, the opportunity for incompatibility is pretty moderate. So, changing all references from TTML1 to TTML2 is a pretty risky thing to do in a new profile where we intend that it be compatible with version N-1, specifically such that IMSCvNext rendering results in the same output as from IMSC1.0.1. Unless there is a conscious intent to extend a TTML1 feature in TTML2 it would be a lot safer to reference TTML1 for all the features found in IMSC1.0.1 and only reference TTML2 for new features or features that were intentionally extended in a backwards compatible manner.

[palemieux]

See related issue against TTML2 [1] recommending that TTML2 be explicitly be made compatible with TTML1.

w3c/ttml2#442

[css-meeting-bot]

The Working Group just discussed IMSC Issues, and agreed to the following resolutions:

• SUMMARY: Mike to study TTML2 §3.4 and propose any modifications.

The full IRC log of that discussion

<nigel> Pierre: Mike brought up two issues: a) if all IMSC vNext references should be to TTML2,
<nigel> .. and if TTML2 is in fact a superset of TTML1 and processing a TTML1 document with the
<nigel> .. TTML2 processor will yield the same result.
<nigel> .. b) deprecation of smpte:backgroundImage - to me that was a good exercise to try
<nigel> .. deprecating that.
<nigel> github: https://github.com//issues/258
<nigel> Mike: I was concerned that the focus has shifted from being an extension of IMSC 1.0.1
<nigel> .. to being a subset of TTML2 and those things aren't necessarily incompatible but they
<nigel> .. change the risk profile, so I'd like the group to consider the choice here. It may be that
<nigel> .. we have to reference both TTML1 and TTML2, but changing everything to TTML2 when
<nigel> .. there's a risk that the processing would change.
<nigel> Nigel: I've always thought that TTML2 is a superset of TTML1, and I've never seen anything
<nigel> .. that made me doubt that.
<nigel> Pierre: There's a related issue w3c/ttml2#442 requesting that the scope of TTML2 is
<nigel> .. defined as a superset of TTML1. For example there are changes to prose for style resolution.
<nigel> Glenn: Something to bear in mind is that a TTML2 document will be processed differently
<nigel> .. by a TTML1 processor and a TTML2 processor. But more importantly if a TTML2
<nigel> .. processor is processing a TTML1 document then its incumbent on the implementation
<nigel> .. to behave modally as a TTML1 processor. It's not completely clear what we're talking about.
<nigel> Mike: We need to make a fundamental decision that either IMSC vNext is a superset of
<nigel> .. IMSC 1.0.1 or a subset of TTML2. Based on what Glenn just said I'm really concerned here
<nigel> .. about replacing TTML1 references with TTML2 ones.
<nigel> Andreas: I think this is really important, that IMSC vNext is a strict superset of 1.0.1.
<nigel> .. The question for this superset in the next version of which version of TTML should be
<nigel> .. referenced for already present features is not easy to answer. If we change any TTML1
<nigel> .. reference to TTML2 that could be a blocker for adoption of IMSC vNext because all
<nigel> .. implementers need to check everything that's referenced and verify that their
<nigel> .. implementation is still compliant.
<nigel> Pierre: I thought the goal was to make TTML2 a superset of TTML1, but are you saying
<nigel> .. that a TTML2 processor would process a document differently from a TTML1 processor?
<nigel> Glenn: Not if it is processing it as a TTML1 processor.
<nigel> Pierre: What has changed?
<nigel> Glenn: Lots of things, I'd have to check. Looking at the version number, treating origin and
<nigel> .. position if both are present - if processing as a TTML2 document it would use position
<nigel> .. in preference to origin.
<nigel> Nigel: I think that's a different question - position would never be present in a TTML1-only document.
<nigel> Mike: But other TTML2 properties may be added to a TTML1 document, such as disparity,
<nigel> .. as has been adopted by ATSC. If the presence of that TTML2 attribute triggers different
<nigel> .. processing of the whole document than in TTML1 that would be a worry.
<nigel> Glenn: It may be that we need to think about this a bit more.
<nigel> Pierre: I'm happy to back out the TTML2 references and replace by TTML1 in IMSC vNext,
<nigel> .. or I'm equally happy to make TTML2 a superset of TTML1.
<nigel> Glenn: It is a superset in that it supports the features. The question is which mode is it
<nigel> .. operating in, either with the knowledge of some fixes relative to TTML1, or if the author
<nigel> .. declares that it's a TTML2 document, and puts a version="2" parameter on it, then the
<nigel> .. author has said that TTML2 rules should apply.
<nigel> .. I don't see this as a binary answer.
<nigel> Mike: In the case of TTML1 vs TTML2 we can sort that out as we go, but in the case of
<nigel> .. IMSC vNext it's fundamental. If the intent is backwards compatible then that's a different
<nigel> .. thing to "it's compatible with some different behaviours".
<nigel> Glenn: I agree
<nigel> Mike: I'm aligned with Andreas that IMSC vNext should be a superset of IMSC v1.0.1.
<nigel> Glenn: It may be that when there is an identified difference, I wonder if we can make a default choice without studying each case.
<nigel> .. Absent of information, I would assume that a reference to TTML1 would be a safer bet
<nigel> .. than simply adopting references to TTML2 across the board.
<nigel> Nigel: How does rendering using CSS factor into this, given that we're putting the mappings
<nigel> .. from TTML style attributes to CSS informatively into TTML2?
<nigel> Pierre: If we want to continue referencing TTML1 for processing behaviours but also add
<nigel> .. TTML2 features like ruby, then we will have to create new features for that syntax. We
<nigel> .. can't reference the TTML2 features because that brings the whole TTML2 processing model.
<nigel> s/new features/new extension features
<nigel> Pierre: For disparity it's not an issue but for something like Ruby then it might be an issue.
<nigel> Nigel: Adding something else into the mix here, we have an intention to work on TTML1 Third Edition
<nigel> .. which essentially backports the important fixes to TTML1 Second Edition. Which version
<nigel> .. of TTML1 do we want to reference in IMSC vNext?
<nigel> Pierre: Going back to Andreas's suggestion, if we explicitly state in TTML2 that the
<nigel> .. processor should process TTML1 documents as TTML1 then we'd be good right? Why
<nigel> .. can't we say that?
<nigel> Nigel: I have no reason not to be able to say that.
<nigel> Pierre: Can we say in TTML2 that a TTML2 processor should process a TTML1 document
<nigel> .. exactly as a TTML1 processor?
<nigel> Glenn: Yes, that's always been the goal.
<nigel> .. There are no blanket statements to that effect.
<nigel> Pierre: Then we have the specific issue here that Mike has raised - that ATSC allows
<nigel> .. tts:disparity to be used in a TTML1 document without specifying ttp:version="2".
<nigel> .. Could one solution in the case of IMSC vNext be never to use ttp:version="2" except when
<nigel> .. using a whitelist of features that are known to affect the processing model. Or prohibit
<nigel> .. ttp:version altogether?
<nigel> Andreas: A question for my understtanding for ttp:version - if we have a TTML1 document
<nigel> .. and we add ttp:version="2" the rendered outcome of a TTML1 document would be no
<nigel> .. different from a TTML1 processor at the moment? That should not have any effect on the
<nigel> .. outcome.
<nigel> Pierre: The particular example that Glenn brought up is position, if ttp:version="2".
<nigel> Glenn: More substantively if there's no profile present then signalling ttp:version="2"
<nigel> .. causes selection of a different default profile. If it is missing then the default would be
<nigel> .. as in TTML1, the old DFXP profiles. However if ttp:version="2" is present then it would
<nigel> .. substitute the TTML2 default profiles which bring in new processor profile defaults.
<nigel> Pierre: If ttp:version is absent, and a TTML2 processor encounters a ruby element what does
<nigel> .. it do?
<nigel> Glenn: It depends on whether it is processing it as a TTML1 or a TTML2 document, independently of ttp:version.
<nigel> .. If it is processing as a TTML1 document then it might ignore ruby even if it knows how
<nigel> .. to process ruby. That's an implementation choice. We can't from a spec perspective
<nigel> .. mandate the implementation in terms of backward compatibility in this regard.
<nigel> Pierre: If we remove ttp:version and let profile signalling completely drive processing then
<nigel> .. there would be no ambiguity.
<nigel> Mike: An IMSC1.0.1 document could add all the vNext features, and the processor might
<nigel> .. understand it, then the version becomes critical, because you're explicitly telling the processor
<nigel> .. to do something different.
<nigel> Pierre: In the case of IMSC vNext there would be a profile identifier so version wouldn't be needed.
<nigel> Glenn: I disagree. We changed the profile mechanism. The processor needs to know which
<nigel> .. profile processing system is being used.
<nigel> Pierre: The mere presence of ttp:contentProfiles signals that the new system is being used.
<nigel> .. The processor can unambiguously identify which TTML version it would be using.
<nigel> Glenn: You're suggesting removing ttp:version and adding an algorithm for deriving the
<nigel> .. TTML version being used. I don't see that as being any different.
<nigel> Pierre: I'm addressing the case identified by Mike that everyone might start putting ttp:version="2" in the IMSC documents.
<nigel> Glenn: That's maybe something that IMSC vNext should say something about but I see it
<nigel> .. as a different issue from what is in TTML2.
<nigel> Pierre: TTML2 requires ttp:version="2" if any TTML2 feature is used including ttp:contentProfile.
<nigel> .. That's what the thread has said.
<nigel> Glenn: No you're overstating it. I said if an author requires TTML2 processing they can
<nigel> .. specify it. They can still not do so. If they fail to do so then it would still provide some sort
<nigel> .. processing dependent on the implementation. I guess the question is what should TTML2
<nigel> .. say regarding documents without ttp:version that do use a TTML2 feature. My response
<nigel> .. would be as an implementer, since the author hasn't said it is required, I would derive it
<nigel> .. using other methods, for example seeing if contentProfiles were present. I don't know
<nigel> .. what you can say about authors blanket putting ttp:version in the document. Maybe add
<nigel> .. a big warning saying "If you put ttp:version="2" then that may cause processing differences in TTMl2 processors compared to TTML1".
<nigel> Pierre: What will ATSC signal as the profile in documents with tts:disparity?
<nigel> Mike: There's no choice, just IMSC 1.0.1 with the extensions and with no other signalling.
<nigel> .. I don't remember if we suggested explicitly stating the profile.
<nigel> Pierre: Yes, IMSC, absolutely.
<nigel> Mike: Ok, but there's no version, or other profile and there probably never will be. To the
<nigel> .. extent that IMSC 1 is deployed in the US, nobody believes that the additions in IMSC vNext are needed.
<nigel> .. If the additions land somewhere else, in a different country, what is an ATSC decoder
<nigel> .. going to do? I don't know, this isn't heading in a good direction...
<nigel> Pierre: Imagine an IMSC 1 processor - it would ignore tts:disparity.
<nigel> Mike: The ATSC processor would know what to do with it. It was explicitly agreed by this
<nigel> .. group that an IMSC processor ignore attributes it doesn't understand.
<nigel> Pierre: Now the same document appears in a non-ATSC decoder, but one that is IMSC vNext,
<nigel> .. and it is labelled as IMSC v1 and there's no profile, and it has tts:disparity, are we trying
<nigel> .. to solve the case of what it does?
<nigel> Andreas: Isn't the question if we can make IMSC vNext use TTML2 features in a TTML1 processor?
<nigel> .. If a TTML2 feature is used then the processor must be a TTML2 processor.
<nigel> Pierre: It's hard to specify that, is TTML2 processing required whenever a TTML2 feature is encountered?
<nigel> Glenn: Here's something to consider: a complicated thing was introduced in HTML5 - is it compatible with previous specifications?
<nigel> .. Probably not. Have implementers verified that it's compatible with their own implementations?
<nigel> .. Probably not. It was just defined. We have a similar issue. We have to go ahead with
<nigel> .. caution about changes that affect processing in older processors. I don't know how we
<nigel> .. check that we don't break compatibility. It's not out intention to break it, and I don't have
<nigel> .. a list where we have made that decision either.
<nigel> Mike: I understand the analogy, I'm not sure it's a good one.
<nigel> Nigel: It's hard to move from the abstract to the concrete without any specific examples
<nigel> .. where a TTML2 processor has a significantly worse presentation than a TTML2 processor
<nigel> .. for a TTML1 document.
<nigel> Pierre: I'm encouraged by Glenn's response that there's no intention to differ. Glenn, do
<nigel> .. you have any objection to making a blanket statement in TTML2 that a TTML2 processor
<nigel> .. processing a TTML1 document should yield identical results?
<nigel> Mike: Be careful of the language.
<nigel> Glenn: TBD the language, but I have no reason to object to doing so.
<nigel> .. The question is do we want to introduce extra language. I think I added a compatibility section.
<nigel> Pierre: I would add it up front in the scope so the objective is clear.
<nigel> Glenn: Putting that in the front matter should be okay. I'm just going to find the section I think I added.
<nigel> Andreas: [I have to drop off] I support what Pierre suggested. It's a good opportunity to
<nigel> .. start the IMSC requirements and to keep the backward compatibility, which means that
<nigel> .. a TTML2 feature being used in an IMSC vNext processor would not change any TTML1
<nigel> .. features used in IMSC.
<nigel> Glenn: I added §3.4 under conformance, and it has forward and backward sections. It is
<nigel> .. marked as non-normative but says things along the lines of what we're talking about.
<nigel> Mike: The conformance is one angle - it's important that a presentation processor also
<nigel> .. does the same thing.
<nigel> .. Currently all the language is about conformance of documents as opposed to rendering.
<nigel> .. Let's work on the language a bit - I'll take a run at it.
<nigel> Glenn: It's §3.4 in TTML2.
<nigel> .. I recall we had a look at this in the past for TTML2 too.
<nigel> SUMMARY: Mike to study TTML2 §3.4 and propose any modifications.

[palemieux]

Propose to close in light of w3c/ttml2#442

[css-meeting-bot]

The Working Group just discussed Replacing references from TTML1 to TTML2 imsc#258, and agreed to the following resolutions:

• RESOLUTION: Close this issue with no change.

The full IRC log of that discussion

<nigel> Topic: Replacing references from TTML1 to TTML2 imsc#258
<nigel> github: https://github.com//issues/258
<nigel> Nigel: @mikedo hasn't responded here since 5th October.
<nigel> .. There's a proposal with one +1 (from me) to close.
<nigel> RESOLUTION: Close this issue with no change.