Clarify that descendants of conditionally excluded elements cannot be included

[nigelmegitt]

See https://github.com/w3c/ttml2/pull/900/files/204ff46225830b23a2c6a4ca7f147cbdd68956d6..9c9a3efb6b2e938d098eff732dcdbca45f791943#r204399436

Need to clarify that the text in 8.2.1 condition (attribute):

if an element specifies a condition attribute, and the its <condition> expression value evaluates to false, then the semantics of the element and its descendant elements must be ignored unless explicitly specified otherwise.

does not mean that a descendant with a condition attribute which evaluates to true becomes conditionally included.

Also remove the qualifier "conditionally excluded" before "descendants" in the note introduced by #900 at the end of §8.2.1.

[nigelmegitt]

On the basis that this change is needed to clarify an ambiguity present before, it counts as a substantive change in regards to the Process.

[skynavga]

I do not agree there is either an existing ambiguity or a need to suppose one. In particular, the value of @condition is never defined as conditionally including an element, only conditionally excluding an element. Conditional inclusion is defined as the negation of exclusion. Therefore, it is not possible to construe a non-false value of @condition as meaning inclusion. Finally, the issue of descendant exclusion is a side effect of labeling an element as being conditionally excluded. Consequently, we have the following predicates:

isConditionallyExcluded(E):
  if E.isConditionallyExcluded
    return true
  else if someAncestor(E).isConditionallyExcluded
    return true
  else if condition && !evaluate(condition))
    return (E.isConditionallyExcluded = true)
  else
    return false

isConditionallyIncluded(E):
  return !isConditionallyExcluded(E)

[nigelmegitt]

@skynavga That'd be fine if it were what the spec says, but it is not. The first line of the section on the condition attribute says:

The condition attribute is used to conditionally exclude or include an element from semantic processing

This suggests, at the very least, that the condition attribute can be used to conditionally include an element.

Further, the text:

For the purpose of presentation processing, if an element specifies a condition attribute, and the its <condition> expression value evaluates to false, then the semantics of the element and its descendant elements must be ignored unless explicitly specified otherwise.

can easily be read as "unless a descendant element's <condition> expression evaluates to true", since it is not clear where the specification of "otherwise" happens, i.e. it could be read as being this specification document or it could be in the document instance.

[skynavga]

@nigelmegitt I think it is pretty clear from the definitions under [conditionally excluded (included)] make it clear that the interpretation you are worried about does not apply:

If the condition expression of a conditionalized element evaluates to false, then the element and its descendant elements are said to be conditionally excluded. If an element is not conditionally excluded, then it is said to be conditionally included.

However, I agree that the language under @condition does not adequately make reference to these definitions. Therefore, I will post a new PR which should accomplish this task. I will also remove the "or include" language you cite above.

[nigelmegitt]

@skynavga That's coming over as slightly rude, to be honest. Why not just take what has already been done in the pull request and comment on that? I'm happy to modify it in response to suggestions.

[skynavga]

@nigelmegitt posted new PR #929 that handles this editorially

[skynavga]

@nigelmegitt because we are not going to obtain quick resolution when I comment that each and every change you proposed is not correct, not desired, or not relevant to the original issue (e.g., you added a lengthy additional example in a note); doing a separate, extremely simple, editorial PR makes the most sense; rudeness has nothing to do with it

[skynavga]

As the chair and editor are apparently at an impasse on this issue, it cannot be processed in time for CR3 CfC; however, we can process it as an editorial change during PR (if desired). Otherwise, we will need to push out to ttml.next. In the mean time, I am changing the milestone on this to PR, on the assumption that #929 is an editorial fix (which I claim it to be).

[skynavga]

Merged early per WG resolution to move forward with CR3 CfC.