Elaborate + and | operators further.

[nigelmegitt]

The codecs parameter is defined to take a syntax that allows for optional (|) or combined ('+') processor profiles, and references https://www.w3.org/TR/ttml2/#profile-attribute-processorProfileCombination however that section does not define those operators further.

In particular we need to explain if the + operator implies that it is acceptable or even required to perform processor profile combination as per TTML2 prior to assessing processor acceptability, in which case:

• the order of operands matters (i.e. perhaps surprisingly the operator is not commutative)
• which value of the combine attribute applies - the first/second/strictest?

As currently written it appears that processor profile combination is orthogonal, since the text just says that + means that both processor profiles apply. From that perspective, the pointer to processor profile combination is perhaps misleading.

[cconcolato]

we need to explain if the + operator implies that it is acceptable or even required to perform processor profile combination as per TTML2 prior to assessing processor acceptability

The operators in the codecs parameter are meant to be used before the document is downloaded/opened. I

I think the reference to processor profile combination is not clear but the intent was to provide a normative definition of how the operators behave. I think + is meant to behave like mostRestrictive and | like leastRestrictive.

Note also the use of 'must' in an "The example:" paragraph in a non-normative section...

[skynavga]

Actually, the intent of "|" and "+" was to serve as a shorthand for the any(...) and all(...) syntax defined for use with the ttp:processorProfiles attribute as defined by https://www.w3.org/TR/2018/REC-ttml2-20181108/#profile-attribute-processorProfiles. However, that section of TTML2 does not formally map that logic onto the TTML profile combination method logic, which is something we should consider adding in TTML2 2e.

Notwithstanding the above, the codecs parameter goes even further by permitting a combination of any(...) and all(...) that is not directly supported in TTML2. We should probably either impose (new) restrictions on the codecs parameter or extend TTML2 to support such combinations in the ttp:processorProfiles attribute.

[css-meeting-bot]

The Timed Text Working Group just discussed Elaborate + and | operators further. tt-profile-registry #62.

The full IRC log of that discussion

<nigel> Topic: Elaborate + and | operators further. tt-profile-registry #62
<nigel> github: https://github.com//issues/62
<nigel> Glenn: I added a comment after the last meeting that the intent of the + and | operators is not to map
<nigel> .. directly to a combination method in TTML2 but to serve as a shorthand for the any and all syntax defined for
<nigel> .. use with the processorProfiles attribute currently defined.
<nigel> .. There's no mapping of those to the combination method logic which is an interesting point
<nigel> .. and potential discrepancy for us to address.
<nigel> .. Another point I noted was that the syntax we defined for these operators allows for a combination of any and all
<nigel> .. which is not directly supported by processorProfiles which raises a question if we should have those combinations
<nigel> .. or if we should add the support to the attribute or restrict codecs to disallow them.
<nigel> .. Those are questions in my mind that I need guidance from the group on.
<nigel> .. If we make any changes then they would need an IANA registration because they are in the body of the media
<nigel> .. type registration, so I'd like to hear what the group thinks in this regard.
<nigel> q+
<nigel> .. It's possible to have a richer logic here that is not directly supported in TTML2 on the presumption that
<nigel> .. processing them is done in the envelope before TTML2 processing per se, as a precursor.
<nigel> .. If that is the case then there is no strong mandate to support combination of the two operators.
<nigel> .. But I wanted to mention that it is possible to have a larger set of semantics apply to codecs than we have at the moment.
<nigel> Nigel: My view is we should not change the media type registration and instead add an informative
<nigel> .. link to the processorProfiles algorithm in case computation of combined processor profiles is desired,
<nigel> .. and we should also further explain the processorProfiles combination algorithms in TTML2 with respect to the
<nigel> .. combine semantics.
<nigel> ack ni
<nigel> Glenn: What do you have in mind, a note in the body of the media type where it talks about the two operators?
<nigel> .. Something to say that the two operators are intended to be similar functionally to any and all in processorProfiles?
<plh> Nigel: you may want to use the processor profile mechanism to compute, but there is no requirement to do so
<nigel> Glenn: Please could you add comments in the issue so we can continue the conversation?
<nigel> Nigel: Yes, will do.
<nigel> q?