ttp:profile on root, and conformance terminology

[nigelmegitt]

We don't say what processors may do with prohibited features (presumably they're permitted to support them).

There's some potential confusion about the mapping from DAPT conformance language to TTML2 feature disposition terminology that we should address too.

We probably need a way to deal with the intended approach to the tt@ttp:profile attribute using appropriate TTML2 terminology.

Source for this issue:

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.

Originally posted by @skynavga in w3c/ttml2#1261 (comment)

[nigelmegitt]

Ready for review at #103.

[css-meeting-bot]

The Timed Text Working Group just discussed ttp:profile on root, and conformance terminology w3c/dapt#104, and agreed to the following:

• SUMMARY: @nigelmegitt to continue talking to @skynavga about how to simplify this.

The full IRC log of that discussion

<nigel> Subtopic: ttp:profile on root, and conformance terminology #104
<nigel> github: https://github.com//issues/104
<nigel> Cyril: I'm happy that we're digging into this but we need to make it easy for new folk to understand.
<nigel> Nigel: I think #103 is improving this.
<nigel> Cyril: From a video world, having two profiles is confusing and we need to clarify it.
<nigel> .. They don't know about processor profile vs content profile.
<nigel> Nigel: This issue came from a conversation with Glenn about some things I wanted to do that
<nigel> .. TTML2 didn't seem to allow.
<nigel> .. The starting point is TTML1 backwards compatibility.
<nigel> .. For DAPT, we simply aren't interested in that.
<nigel> .. We only want to use contentProfiles and possibly optionally processorProfiles, but not ttp:profile
<nigel> .. but all the relevant feature designators in TTML2 include the TTML1 #profile, and effectively require
<nigel> .. implementers to code for ttp:profile even though we are prohibiting its use.
<nigel> .. Glenn proposed a way to express this in the formal language of TTML2 profiles, which I've done
<nigel> .. in #103. It essentially defines an extension for this one thing and says "this is prohibited".
<nigel> .. There's a message from Glenn that I haven't read yet about TTML2 handling of different values of the
<nigel> .. value attribute on the ttp:feature element.
<nigel> .. The essence is we want to be able to say "it's permitted in a document, and must be implemented in a processor"
<nigel> .. which doesn't seem possible in TTML2. I think he's pointing me at something I missed.
<nigel> Cyril: Every standard has that, optional features that must be supported by the player.
<nigel> Nigel: Of course!
<nigel> Cyril: I'm not clear about this processor profile part.
<nigel> Nigel: One of the things I've done is move the profile definition into the appendix, still normative,
<nigel> .. but kept the important/interesting stuff that we need people to understand to before the appendices.
<nigel> .. It keeps the formality but makes the document seem shorter.
<nigel> Cyril: I like that idea.
<nigel> Nigel: At the moment I've had to define a content profile and a processor profile distinctly,
<nigel> .. and it'd be much better if we could have only one. I will keep working with Glenn to understand if
<nigel> .. I can actually do that.
<nigel> SUMMARY: @nigelmegitt to continue talking to @skynavga about how to simplify this.