Prohibit usesForced named metadata item

[palemieux]

itts:forcedDisplay is used instead (and deprecated in favor of using dedicated document for forced text). The #metadata-item feature implies support for all named metadata items.

[nigelmegitt]

I don't think there's a problem with implying support for all named metadata items, is there?

[palemieux]

I think we need to avoid users/implementers thinking that using the usesForced named metadata item has any effect on the processing of the IMSC 1.1 document.

[nigelmegitt]

This should simply be advice that using usesForced metadata has no effect on processing. We should not go any further than that.

[palemieux]

@nigelmegitt usesForced is defined as A boolean that expresses whether some expression makes use of the forced bound parameter, where the value adheres to xsd:boolean. usesForced cannot be present since condition is prohibited. So why not also prohibit usesForced to avoid any confusion?

[nigelmegitt]

@palemieux usesForced can be present regardless of whether or not condition is permitted. It can be used simply in a descriptive sense, for example so that an asset management system can inspect a document's /tt/head/[metadata class children] to discover if the document claims to use forced or not. The semantic intent can be used, but based on itts:forcedDisplay rather than the forced bound parameter.

[palemieux]

@nigelmegitt Then that intent must be clarified in TTML2, because it is intimately tied to condition right now.

[nigelmegitt]

@palemieux Yes, that would be good, to loosen the coupling in TTML2. I've raised w3c/ttml2#609 proposing a looser definition that, if accepted, would remove the question of prohibiting usesForced in IMSC1.1.

[palemieux]

Per w3c/ttml2#609 (comment) , propose that IMSC note the non-applicability, plus possibly recommend non-usage.

[nigelmegitt]

Re #311 (comment) from yesterday's meeting, I believe we have consensus for this option, i.e. nobody objected to it during the call.

[nigelmegitt]

This should have been closed by #314 being merged, I'm not sure why it wasn't. Thanks for picking it up @palemieux .