Re: ttp:version is not required for processor capability signaling

Firstly, I want to raise a procedural issue, which is in regard to the
reopening of a decision taken by the group. We have now published TTML2 WD
five times, starting 2015-02-17, and each time, the group approved the
content of each of these WDs, all of which include the specification of
ttp:version. Until now, there has been no question about the inclusion of
ttp:version in TTML2, and, under this assumption, significant activity has
occurred in order to implement, test, and use this mechanism. Until now,
and in the new comments that have emerged, there is no claim (as far as I
can discern) that this mechanism is technically flawed, or broken in any
way. Furthermore, no new information has been put forward that would permit
us to revisit the prior decisions that resulted in accepting this feature.
As a result, our standing policy applies, which is that the earlier
decisions stand. Consequently, the burden of proof on excluding this
feature lies with the proposer.

Secondly, the purpose of this feature is to assist in future-proofing TTML
as it evolves to include new versions of the TTML language family, each of
which is expected to define new syntactic features and/or new semantics
that did not previously exist.

Thirdly, the three claims described below are not true:

(1) the use of #profile, ttp:processorProfile, and/or ttp:contentProfile
does not allow the author to specify version distinctions that are not
otherwise bound to the designation of a profile; for example, the inclusion
of ttp:version='2' in an otherwise conformant TTML1 document causes a TTML2
processor to interpret the document according to TTML2 semantics even in
the absence of any designation of profile;

(2) if a document contains both tts:origin and tts:position, a TTML1
processor will employ the former, since it knows nothing of the latter;
however, a TTML2 processor knows about both, and must be told whether to
process using TTML1 semantics (choose tts:origin) or TTML2 semantics
(choose tts:position); therefore, it is necessary to evaluate ttp:version
to determine which set of semantics to employ;

(3) ttp:version is not used to signal deprecation; rather, ttp:version is
used to signal use of a specific TTML specification and its semantics, one
such semantic being that, for ttp:version='2' (TTML2), certain deprecation
semantics apply; the point about validity and validation is orthogonal to
(and irrelevant to) the designation and processing of deprecation semantics;

Next, though it is not stated below, it has been implied that the
specification version to be applied can be inferred from the set of
features used in the document, e.g., that a processor might infer that
TTML2 semantics apply if ttp:contentProfiles or ttp:processorProfiles is
present; however, clearly this is not the case, since a future version >2
may include all features defined in version=2, etc., so, for example,
ttp:version='3' might include both ttp:contentProfiles and
ttp:processorProfiles (and every other syntactic feature defined in TTML2),
so a future TTML3 processor would not be able to reliably determine whether
TTML2 or TTML3 semantics apply.

Finally, the use of version information to self-identify assumptions about
content and its processing is a well-established and well-used technology,
both within the W3C and without. In conclusion, no change is warranted, and
no further consideration should be given this matter unless the proposer
provides new information that would lead to a re-opening of multiple, prior
group decisions.

On Fri, Nov 10, 2017 at 5:30 PM, Pierre-Anthony Lemieux <pal@sandflow.com>
wrote:

> Good morning/evening,
>
> Following-up on our F2F, below is a discussion re: ttp:version should
> not be used to signal processor requirements in TTML2, and can likely
> be entirely removed.
>
> 1. The profiling vocabulary and semantics (#profile,
> ttp:processorProfiles, ttp:contentProfiles...) allows the author to
> precisely specify the capabilities needed to process the document,
> removing the need for ttp:version to signal default profiles (Section
> 5.2.4.3). This would moot issue #435.
>
> 2. ttp:version currently overrides TTML1 processor behavior in absence
> of both tts:origin and tts:position (Section 11.1.2). I found no
> concrete requirements for such override, which can, in any case, (i)
> be signaled using the #initial feature or (ii) be explicitly triggered
> by specifying tts:position.
>
> 3. ttp:version is currently used to signal deprecation of offset-time
> and clock-time forms when the governing time base is smpte (Section
> 12.3.1). Deprecation is not a prohibition, and can therefore be
> accomplished without using ttp:version, i.e. a TTML1 document would
> remain a valid TTML2 document if TTML2 simply deprecated these two
> scenarios.
>
> Best,
>
> -- Pierre
>
>