Clarify version negotiation or lack thereof

[samuelweiler]

I'd like to see a direct discussion of how version negotiation (TTML2 v. TTML2 "(2nd Edition)") is done. If it's not done, explaining that in the privacy considerations section would be grand.

[skynavga]

TTML (in general) does not specify version negotiation. However, see the Profile mechanisms, which allow a document to specify which TTML profile applies to content and what profile is required by a processor.

https://www.w3.org/TR/2020/CR-ttml2-20200128/#vocabulary-profiling

[samuelweiler]

While you're welcome to close this, I think addressing it might make the next PING review of this spec go more smoothly.

[skynavga]

I don't believe any more PING reviews will be requested for 2nd Edition, so it is best to await a possibly future request before further reviewing. Moreover, the current spec language around processor profile processing states:

A processor profile is used to allow an author to declare, at authoring time, what processing must be supported when processing a document instance, such that, if a processor is not able to perform the indicated processing, then processing should be aborted. Such a declaration permits downstream processors to avoid processing content that cannot be processed in a manner that meets the requirements of the content author.

Note that aborting processing is not mandatory (on the occasion of an [unsupported or disabled] author mandated processor feature), so a (paranoid) privacy minded processor might choose to never abort, thus depriving an author of observing a change in behavior. But such a processor would be constructed by only privacy (paranoid) implementers, who should know what to do without TTML giving them any (redundant) advice. TTML permits a range [1] of (undefined) behaviors, namely [emphasis added]:

abort processing of the document instance unless overridden by the end-user or some implementation specific parameter traceable to an end-user or to a user or system configuration setting;

[1] https://www.w3.org/TR/2020/CR-ttml2-20200128/#semantics-procedure-abort-if-unsupported-processor-profile

[nigelmegitt]

I don't think we've clarified the request enough to close this yet, so reopening.

@samuelweiler when you say "version negotiation", considering that TTML is a document format not an API, I'm unsure what behaviour you hope to see discussed. When scoping changes to TTML versions or editions, one of the things we take into account is the significance and impact of the change.

As you can see from the change log, there are syntactic changes, that could mean that a TTML2 (1st edition) processor would not successfully process a TTML2 2nd edition document, and vice versa, though as @skynavga has pointed out, the behaviour of processors on encountering unexpected content is deliberately left flexible for the implementation.

My reading of the changes is that I don't think any such failure to process could result in any privacy issue. Nevertheless, it would be possible at least in principle to create new registry entries in the TTML Media Type Definition and Profile Registry that distinguish between TTML2 1st Edition and TTML2 2nd Edition.

TTWG has not discussed what to do with the profile registry's TTML2 entries so far, and would typically wait until transition to Rec before making any updates.