Loosen coupling between item name="usesForced" and forced.

[nigelmegitt]

The "usesForced" named metadata item definition is very tightly coupled with use of condition in the document instance, in relation to the forced bound parameter. This means it cannot be used in other contexts that may define some forced functionality. See also the thread leading up to w3c/imsc#311 (comment)

Additionally, only one scope of usage is defined, at the document level. It would seem a reasonable optional usage to be able to scope it to an element in the body content such as div etc.

Since no processing semantic is based on the metadata item, there we can be less prescriptive about its usage. This will also have the effect of reducing the implementation and test burden.

Instead of the current wording:

A boolean that expresses whether some <condition> expression makes use of the forced bound parameter, where the value adheres to xsd:boolean. If this named metadata item is present in a document instance, then it must be specified as a child of the head element.

I propose:

A boolean that expresses whether some content within the specifying element's scope makes use of forced display semantics, where the value adheres to xsd:boolean. If this named metadata item is specified as a child of the head element then the applicable scope is the whole document; if specified as a child of a content element, then the applicable scope is that element and its descendants.
Note:
Forced display semantics can be expressed by use of the forced bound parameter within a <condition> expression.

[skynavga]

I object to this proposed change: usesForced is explicitly intended to being scoped to use of the forced @condition parameter and (2) apply to document scope only. Further generalization is not supported by use cases.

[nigelmegitt]

To the contrary @skynavga there is a use case that arises from the thread referenced in the issue - to allow usesForced to be used in contexts that apply forced display semantics using other mechanisms, and conversely to avoid the need to prohibit its use where the forced @condition parameter is not available, such as in IMSC 1.1.

[skynavga]

@nigelmegitt I might be able to agree to generalize to other uses, but will not agree to fine grained scoping. It is either document level scope or nothing.

[nigelmegitt]

Why the objection to fine grained scoping?

[skynavga]

On Tue, Jan 30, 2018 at 4:21 AM, Nigel Megitt ***@***.***> wrote: Why the objection to fine grained scoping?

Because that defeats the entire purpose of this mechanism, which is to have a top-level, easy to find indicator of use of forced content in the document without having to parse the entire document. There would be no purpose for usedForced if you have to parse the entire document to find it. You could just as easily parse the entire document to find the conditions that cause one to apply usesForced to the entire document in the first place.

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#609 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb8-xxbAJXrh1jC5UVZahCrTaKay3ks5tPvstgaJpZM4RyIUA> .

[palemieux]

Because that defeats the entire purpose of this mechanism, which is to have
a top-level, easy to find indicator of use of forced content in the
document without having to parse the entire document. There would be no
purpose for usedForced if you have to parse the entire document to find it.

I tend to agree. @nigelmegitt, what would be the counter-argument and/or use case?

[nigelmegitt]

Because that defeats the entire purpose of this mechanism, which is to have a top-level, easy to find indicator of use of forced content in the document without having to parse the entire document.

@skynavga I disagree. If you want document wide indication, then it is exactly the same as it was before - you have to look in /tt/head. However the previously undefined meaning of the usesForced named metadata item on other elements now has additional clarity: it used to be "not significant", now it has limited significance that is not document-wide. In the absence of some definition of the meaning on content elements, someone will probably misuse it, so we may as well direct the meaning now rather than leaving it unstated.

[skynavga]

@nigelmegitt It can't be misused without being nonconformant, due to:

If this named metadata item is present in a document instance, then it must be specified as a child of the head element.

Or, you can rewrite this to read

A usesForced named metadata item is considered to be significant only when specified as a child of the head element.

[nigelmegitt]

@skynavga Those two do not appear equivalent to me, but I would find the second form more reasonable, and also more compatible with the change I am proposing.

Consider a document instance that includes a usesForced metadata item somewhere other than a child of /tt/head: In the first case ("must be specified as a child of the head element") I would expect a validator to issue an error; in the second case ("significant only when specified...") I would expect silence or an informative message or possibly a warning, but not an error, and for the item to be ignored.

The first form is used in the current ED, and it is too strong. We should not specify that a validating presentation processor can even consider aborting processing due to a misplaced named metadata item.

You've convinced me even more that my proposed change is an improvement!

[skynavga]

@nigelmegitt the second form is consistent with other uses of document level information, e.g., see similar statements in all definitions of ttp:* attributes; I am happy to make this change

[nigelmegitt]

In discussion of the pull request an alternative proposal has been raised, to remove the usesForced named metadata item altogether.

Use case

No use case has been presented so far to the group for this named metadata item.

Just in case this was mentioned in the requirements document for TTML at https://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/ I checked this, and it is absent there. (For clarity, I do not believe we are bound by that document in its entirety, and can potentially introduce use cases not considered in that document, but it's fairly comprehensive and has stood the test of time reasonably well; I checked it because if the need for a usesForced metadata item had somehow been represented in that document then the case for keeping it would have been clear.)

History of usesForced discussion in the TTWG

A search reveals that after it was introduced initially without discussion, we talked about it very briefly at the TPAC F2F in Lisbon (minutes) where the group agreed to keep usesForced on the basis that it is referenced elsewhere in the specification. Even at that time there was evidently a request to remove it.

Impact of removal

However, on reviewing this dependency, it seems like it is somewhat arbitrary and the usesForced metadata item name can certainly be removed straightforwardly: there's a reference to it in the forced bound parameter that would need to be removed, but there's no further onward impact than that.

[skynavga]

I object to removal at this time because (1) it does not adhere to common practice of using at-risk to remove features at end of CR; and (2) it prevents performing the IPR disclosure process on this (and other features prematurely removed).

[nigelmegitt]

@skynavga have you seen the related discussion on w3c/imsc#311 that led to this issue being filed? We need to find a route through this in both TTML2 and IMSC 1.1 that is acceptable to everyone. Right now the presence of the usesForced named metadata item, worded in the way that it is, is causing a problem in IMSC 1.1. If you are objecting to removing it from TTML2, then please could you propose a way to address the IMSC 1.1 issue?

[css-meeting-bot]

The Working Group just discussed Loosen coupling between item name="usesForced" and forced. ttml2#609, and agreed to the following resolutions:

• SUMMARY: There are a variety of options and we have no consensus right now.
• SUMMARY: 1. Remove the feature from TTML2.
• SUMMARY: 2. Generalise the description in TTML2 further than condition.
• SUMMARY: 3. Define a feature designator in TTML2 called #metadataUsesForced (or something similar)
• SUMMARY: 4. Do nothing in TTML2 and let IMSC add language to prohibit
• SUMMARY: 5. Do nothing in TTML2 and let IMSC note the non-applicability, plus possibly recommend non-usage.

The full IRC log of that discussion

<nigel> Topic: Loosen coupling between item name="usesForced" and forced. ttml2#609
<nigel> github: https://github.com//issues/609
<nigel> Glenn: Again here I object to removing it. I do not object to modifying the text to allow
<nigel> .. it to cover other uses besides condition, which I think was the reason that this came up
<nigel> .. in IMSC context, because IMSC 1.1 does not include condition (yet).
<nigel> Pierre: I'm going to call for consensus to accept the pull request to remove it, because at
<nigel> .. the moment it is not useful.
<nigel> Andreas: I agree.
<nigel> Nigel: I agree.
<nigel> Cyril: Everything that makes it ambiguous for IMSC 1.1 in terms of forcedDisplay should be
<nigel> .. cleaner. Glenn's proposal is to modify the usesForced parameter to make it clearer, and
<nigel> .. I haven't seen the usage for it, so my preference is to remove it.
<nigel> Glenn: The use case for this is to provide a top level way to determine if the document
<nigel> .. uses forced or not and process it in a special way if it does uses forced.
<nigel> Cyril: That's the problem. Pure metadata is maybe harmless, but if there is processing
<nigel> .. associated then that's a problem.
<nigel> Glenn: It's metadata but no processing is defined in the spec.
<nigel> Pierre: My point is that will lead to intense confusion if some application uses it.
<nigel> Nigel: No case was ever made for this named metadata item - it was added without discussion.
<nigel> .. I'm not aware of anyone who has ever asked for it.
<nigel> Cyril: I want to remove this.
<nigel> Pierre: I propose to remove it and if Glenn wants to object to it then log that and take it forwards.
<nigel> Nigel: To do that then I will have to dismiss the review and merge it. I would then have to note the objection and carry it forward in the CR transition request.
<nigel> Glenn: I would note that the WG has signed off on this feature previously in other WDs in
<nigel> .. which this feature was included. Now the group is attempting to remove it without
<nigel> .. identifying the feature as at risk, which can be done more easily.
<nigel> Cyril: I propose a different option - the IMSC issue is about the feature being too broad.
<nigel> .. I propose two features, one per named metadata item #usesForced and #altText.
<nigel> .. Would that resolve it in IMSC1.1 Pierre?
<nigel> Pierre: That would resolve it for me since I could prohibit it from IMSC 1.1.
<nigel> Glenn: You want feature designators for individual named items? I could accept that.
<nigel> Nigel: That would not resolve my issue, which is that prohibiting metadata items within
<nigel> .. IMSC 1.1 that are harmless is too draconian.
<nigel> Glenn: My alternative proposal is to make the change to usesForced so that it does not
<nigel> .. require condition, so that it could be used in IMSC 1.1.
<nigel> Nigel: The best option here is to remove the usesForced metadata item.
<nigel> Pierre: I'd rather remove usesForced than have Nigel's objection.
<nigel> Andreas: What was your objection Nigel?
<nigel> Nigel: It is too draconian and if it is useful then it would force people who for some reason
<nigel> .. do want to use it to use a different named metadata item, which is crazy.
<nigel> Glenn: I agree that the prohibition is draconian.
<nigel> Cyril: If we were to do nothing in TTML2 we could simply add a note to IMSC 1.1 that for
<nigel> .. the avoidance of doubt, because condition is prohibited in IMSC 1.1 then the metadata
<nigel> .. item is also prohibited.
<nigel> Nigel: You could say it is "not applicable".
<nigel> Glenn: I would say "it does not apply", which is different than prohibiting it.
<nigel> .. Right now in TTML2 it is well defined and there's no technical problem. The issue is only
<nigel> .. with IMSC, which could add clarifying semantics about the exclusion of condition, to say
<nigel> .. that usesForced is predicated on condition and therefore does not apply.
<nigel> Cyril: I would be okay with this pull request not being merged on the basis of that update
<nigel> .. to IMSC 1.1, because it basically cannot be used.
<nigel> Pierre: That's my conclusion as well, so I wanted to prohibit it in IMSC 1.1 to avoid any
<nigel> .. confusion.
<atai2> q+
<nigel> Cyril: The fact that it is prohibited is just a consequence not an extra syntactical constraint.
<nigel> ack atai2
<nigel> Andreas: Would that be acceptable for Nigel and Pierre to use a SHOULD?
<nigel> Cyril: It cannot be a SHOULD, the document would just be wrong if it is used.
<nigel> Nigel: Actually using usesForced="false" would be fine.
<nigel> .. You could have a document that does that and uses IMSC 1.1 usesForced semantics,
<nigel> .. which would be technically correct but rather confusing.
<nigel> Cyril: I would prohibit usesForced altogether, on the grounds that usesForced="false" cannot
<nigel> .. be meaningfully used.
<nigel> Glenn: I'm hearing a proposal to add #usesForced in TTML2 - I would have no problem with that.
<nigel> .. I would also note that the description of usesForced needs an addition to say that absence
<nigel> .. from the document does not imply anything.
<nigel> Pierre: Would you be okay to re-evaluate your objection to prohibiting it?
<nigel> Nigel: I need to think about that. I still think that the best thing is to note that it does not apply.
<nigel> .. Are you going to abort processing because of the presence of metadata?
<nigel> Pierre: For the sake of making sure people don't make mistakes we should prohibit it.
<nigel> Glenn: By that argument you should prohibit all metadata in case it is misused.
<nigel> Nigel: I think it is crazy to abort processing because of the presence of metadata, and
<nigel> .. I don't think anyone would really want to do that.
<nigel> Cyril: I don't think the proposal is to abort processing.
<nigel> Nigel: I think it is.
<nigel> Cyril: The document processor has the freedom to process invalid documents.
<nigel> .. A validator though would detect this and say something is wrong.
<nigel> Nigel: A warning would be sufficient.
<nigel> Glenn: If you said "should not be present" then that would generate a warning.
<nigel> Nigel: Pierre, mirroring your request earlier, would you reconsider your prohibition proposal?
<nigel> Pierre: No presentation processor does validation, practically, in the field.
<nigel> SUMMARY: There are a variety of options and we have no consensus right now.
<nigel> SUMMARY: 1. Remove the feature from TTML2.
<nigel> SUMMARY: 2. Generalise the description in TTML2 further than condition.
<nigel> SUMMARY: 3. Define a feature designator in TTML2 called #metadataUsesForced (or something similar)
<nigel> SUMMARY: 4. Do nothing in TTML2 and let IMSC add language to prohibit
<nigel> SUMMARY: 4. Do nothing in TTML2 and let IMSC note the non-applicability, plus possibly recommend non-usage.
<nigel> s/4/5

[nigelmegitt]

Following further discussion I believe we have consensus for option 5, i.e. do nothing in TTML2 and in IMSC (w3c/imsc#311) note the non-applicability of <ttm:item name="usesForced">true</ttm:item> and on that basis disrecommend its usage, even if itts:forcedDisplay is used in the IMSC 1.1 document instance.