No feature to indicate TTML2 profile attribute vocabulary _only_

[nigelmegitt]

While working on w3c/dapt#43 I noticed that there's no feature that allows only the TTML2 profile attribute vocabulary to be specified, without also requiring support for the TTML1-defined #profile. I expected to see this in #profile-version-2 but that's defined as an extension to #profile and declares it to be an error to prohibit use of #profile and require or permit #profile-version-2.

The possible options are:

1. Define some new feature, excluding #profile, e.g. #profile-exclusive-version-2
2. Just use #contentProfiles and #processorProfiles independently, without also supporting #profile.

This probably doesn't have a very high priority to fix, but I'm raising it because I think in time we should be helping folk move away from tt@ttp:profile usage (i.e. ttp:profile attribute on the tt element), in favour of the newer vocabulary, and the current arrangement only goes half-way, in that it allows people to use both, but not to define a requirement that excludes the older vocabulary.

[skynavga]

I don't view this as something that needs "fixed" since support for #profile is required by #presentation, #presentation-audio, and #transformation features, and thence, #presentation-version-2 and #transformation-version-2.

In addition, the construct effective processor profile procedure step 4 requires treatment of tt@ttp:profile, a consequence of mandatory Generic Processor Conformance, step 2 (perform profile processing).

Finally, the Backwards Compatibility clause indicates that TTML2 is designed to process conforming TTML1 documents, including those that employ tt@ttp:profile, even in such cases as an audio-only TTML presentation processor.

IMO, a better solution is for content aggregators and content services to require that no tt@ttp:profile be present in the TTML2 documents they ingest, but, rather, that #contentProfiles and #processorProfiles be used as an alternative.

[nigelmegitt]

Thanks for that @skynavga. In the DAPT situation we want to make it a TTML2-only document, and explicitly don't care about TTML1 backwards compatibility, and we are indeed prohibiting use of the tt@ttp:profile attribute and requiring use of tt@ttp:contentProfiles with at least one known value corresponding to DAPT.

That being the case, it now looks unfortunate that the feature designators you listed bundle processing requirements for functionality we don't want implementers to have to support.

The upside is that we can roll our own combined set of features that omits #profile, cumbersome though that may be.

Looking at construct effective processor profile procedure step 4, effectively what I'm saying is that it should be feasible for implementers to omit that step, since #profile support is not required.

I also note that the first line definition of #profile concerns the tt@ttp:profile attribute, but then the feature also incorporates support for element vocabulary. Since we will be using a well-known profile designator in ttp:contentProfiles we don't require that any of that vocabulary is supported, though of course support would be permitted.

[skynavga]

I would suggest the following. In DAPT,

1. define #profile-root (scoped to DAPT NS) as supporting semantics of ttp:profile attribute on tt (root) element;
2. specify #profile-root as prohibited in the DAPT content profiles and optional in the DAPT processor profiles;

A comment regarding DAPT Conformance: the term permitted is used multiple times; however, this term is not defined or used in TTML2, so has no meaning in the context of referring to TTML2 profiles. However, the term optional is used by TTML2 and applies equally to content and processor profiles, where it means it may or may not appear in a document (when used with a content profile), and it may or may not be supported by a processor (when used by a processor profile). In contrast, the term permitted, as I understand it, would apply only to a content profile, and not to a processor profile.

[nigelmegitt]

Thanks for the suggestion, that could work. It would still not allow us to use any of the TTML2 features that require support for #profile of course, since that would introduce a requirements conflict.

The conformance terms permitted, optional, required, prohibited used in DAPT are defined in DAPT's Conformance section rather than using their TTML2 definitions. I see that we don't say anything about processor support for features marked as optional, which looks like an omission.

[nigelmegitt]

I think my previous comment regarding conformance language may have been slightly at cross-purposes with what you meant @skynavga - I've opened an issue on DAPT with your comment, and my summary of what needs to be fixed based on it.

[skynavga]

Regarding

It would still not allow us to use any of the TTML2 features that require support for #profile of course, since that would introduce a requirements conflict.

I'm not sure that is true. In particular, see the note at the end of 5.2.1:

A predefined profile is subsetted by specifying some feature or extension to be optional (voluntary) that was specified as required (mandatory) in the underlying, baseline profile.

When a baseline profile is modified by subsetting, the resulting, derived profile is referred to as a subtractive profile;

I would then expect DAPT to specify that #profile-root is prohibited in its content profile but optional in its processor profiles; however, the profile specification in Features does not distinguish between content and processor profiles.

[nigelmegitt]

@skynavga how does that subtractive profile idea interact with text such as:

It is an error for a content profile to require or permit use of the #profile-version-2 feature but prohibit use of any of the following features: #contentProfiles, #processorProfiles, or #profile.

from #profile-version-2 ? On first look, it appears that the spec is prohibiting subtraction in this case, by declaring it to be an error.

[skynavga]

While that is an interesting question, it is a problem for another day since I am suggesting to prohibit a new #profile-root, and not #profile. A bit of subterfuge, but by the letter of the specification, not inconsistent.

In retrospect, we probably should have considered deprecating tt@ttp:profile in 2nd Ed. But that too, can be deferred.

[nigelmegitt]

Thanks again @skynavga - I've implemented your proposal at w3c/dapt#103 along with some other changes. With reference to your point about the conformance terms, it should be clearer how the DAPT dispositions map to the TTML2 ttp:feature and ttp:extension elements' value attributes now.

I'm not sure if there's any urgent work to do in TTML2, but it does seem odd that there's no semantic defined for a processor profile when ttp:feature@value="prohibited" (likewise for ttp:extension@value="prohibited"). I think it should be the same semantic as for optional.

The other addition made in DAPT, absent from TTML2, is the semantic: optional in content, required in processor. The term "permitted" is used for this in DAPT.

[skynavga]

Regarding

I'm not sure if there's any urgent work to do in TTML2, but it does seem odd that there's no semantic defined for a processor profile when ttp:feature@value="prohibited" (likewise for ttp:extension@value="prohibited"). I think it should be the same semantic as for optional.

Actually, it is defined (as mapped to optional) by Table 6-2.

The other addition made in DAPT, absent from TTML2, is the semantic: optional in content, required in processor. The term "permitted" is used for this in DAPT.

I think permitted is not needed in TTML2 since every ttp:feature and ttp:extension element is specified in the context of a ttp:profile element of a specific type (either content or processor).

As an aside, I've never been comfortable with IMSC's introduction of permitted since it has no syntactic counterpart in TTML2 itself. Further, having IMSC (and now DAPT) define profiles without actually including any timed text profile document is troubling. IMO, every TTML profile specification should include (inline) one or more such documents, such as those found in TTML2 itself: Appendix G - Standard Profiles.

[nigelmegitt]

OK, for DAPT where I'd like to define a single profile, I like the idea that I can define it as a content profile and have there be inference rules for what that means for generating a processor profile, and I hadn't paid enough attention to that section, so thanks for the pointer.

The difficulty is that I don't want to have to require ttp:inferProcessorProfileMethod="strict" on every DAPT TTML document instance, but that's the definition in Table 6-2 that we would want, and omitting it, the one that we'd get is the "loose" one.

It seems like a shame right now that the ttp:inferProcessorProfileMethod is only considered significant on the <tt> element: it would be neat to have it on a <ttp:profile> element where type="content" to say "hey, if you're inferring a processor profile from me, do it in a [strict|loose] way".

[nigelmegitt]

I realised overnight that my last comment was not right. Using either loose or strict alone can not achieve what I think we want from a content profile that can be used to infer a processor profile.

The missing category is not in the inferProcessorProfile method, it's in the classification of feature use, and is exactly what is introduced in both IMSC and DAPT to allow some features to be marked as "optional in both content and processor" and others to be marked as "optional in content, required by processor".

That mix of feature states can't be switched on a feature level by inferProcessorProfile at all, because it only acts on a profile level.

I would suggest adding the permitted value to ttp:feature@value and ttp:extension@value but the amount of change required would be quite large. For example Table 6-1 would be much bigger due to the larger number of permutations.

[nigelmegitt]

The solution I have, which feels non-ideal, but safe, is to specify in w3c/dapt#103 the content profile and the processor profile explicitly in the appendix, as timed text profile documents, while keeping the easier-to-read table of feature and extension dispositions.