Clarify undefined semantics for text combine in ruby text (#978).

[skynavga]

Closes #978.

[palemieux]

The second sentence of the note conflicts with the first: if no semantics are specific, than no recommendations or permissions should be specified. Suggest removing the second sentence. Perhaps more importantly, this issue can be deferred until after the ED is generated for horizontal review.

[skynavga]

There is no conflict. The second sentence is a logical consequence of the first sentence. Nevertheless, I will attempt to address your comment by removing the first sentence. I see no need to defer resolving this.

[skynavga]

@palemieux see 838df59

[palemieux]

@skynavga I think the first sentence (now removed) was correct: the specification does not define a behavior so implementation can do as they wish, i.e. may treat it as if the value none or the value all were specified.

[skynavga]

@palemieux Restored the first sentence in 5a6487a. Note that I am still keeping the second sentence, which I insist is not in conflict with the first sentence, and, is indeed, a logical consequence of the first sentence as you yourself point out. However, if you feel it necessary to tweak the second sentence to avoid some reading that I am not seeing, then please propose a specific edit.

[css-meeting-bot]

The Timed Text Working Group just discussed Clarify undefined semantics for text combine in ruby text (#978). ttml2#1171, and agreed to the following:

• SUMMARY: @skynavga to propose alternate wording advising non-use of textCombine in the context of ruby

The full IRC log of that discussion

<nigel> Topic: Clarify undefined semantics for text combine in ruby text (#978). ttml2#1171
<nigel> github: https://github.com//pull/1171
<nigel> Glenn: There appears to be a difference of opinion between myself and Pierre.
<nigel> .. The intent of this was basically to say that in the context of ruby text that text combination has no semantics defined,
<nigel> .. so I had proposed a note that says this version of TTML does not define any semantics for text combine in the context
<nigel> .. of ruby text content and added that presentation processors may ignore text combine (treat as None) in the context
<nigel> .. of ruby text. Pierre doesn't seem to like the second part but I think it's a logical consequence of the first sentence.
<nigel> Pierre: I'm going to repeat myself, but the second sentence specifies a permission and therefore a semantic so it has
<nigel> .. to be removed.
<nigel> Glenn: It is in a note so is not normative.
<nigel> Pierre: Equally it can be removed then.
<nigel> Cyril: Is it the use of "may" that creates confusion?
<nigel> Pierre: Yes, absolutely. I think it is true that there are no semantics, so there are none, period.
<nigel> Glenn: We use "may" in notes.
<nigel> Pierre: If there is no semantic there should be no suggestion one way or another.
<nigel> Cyril: What is the intent, to say "don't use them together because you won't get interop"?
<nigel> .. Or that some implementations may do it right and others may not but if you are using conformant implementations
<nigel> .. then you can still use it.
<nigel> Glenn: Is it the problem that it looks like conformance language.
<nigel> Pierre: That is not my problem, although it is throughout TTML2, I've said before.
<nigel> Nigel: Could we water down the second sentence to say "For example, ... could ignore"?
<nigel> Pierre: And add a contrary example too.
<nigel> Glenn: either would work for me.
<nigel> Cyril: Me too, it's okay.
<nigel> Glenn: We have "for example" elsewhere in notes.
<nigel> Cyril: That means implementers could expect to encounter content with this.
<nigel> Glenn: I wouldn't say should expect but it is possible.
<nigel> Cyril: Is there a defined behaviour?
<nigel> Glenn: This is there to put authors on notice that they should not expect a particular behaviour.
<nigel> Cyril: So we should say do not use it.
<nigel> Glenn: That's going too far.
<nigel> Pierre: I agree with Cyril, the intent is to warn authors not to use it because the implementation is undefined.
<nigel> Glenn: We cannot say "should not be used" in a note - we don't do it in a note.
<nigel> .. In many cases we give fair warning to readers that it is inadvisable.
<nigel> .. This is how we do it.
<nigel> Pierre: Here it is more than that, something could happen, it might not be ignore.
<nigel> Nigel: We're agreeing about the reality of what is specified, just discussing what the best advice is to readers.
<nigel> Cyril: Are we agreed to advise people not to use?
<nigel> .. If we agree that because this feature is not specified people should not rely on it or use it because they might get
<nigel> .. any behaviour? If so then we can work on the text.
<nigel> Glenn: Generally we don't say in TTML that authors should use or not use something. That's a profile question.
<nigel> Cyril: Do you agree on the intent here, that "unspecified behaviour" means anything could happen?
<nigel> Glenn: I agree, we don't want users to use something that is undefined.
<nigel> Cyril: I agree with Pierre that if we hint that it will be ignored people might rely on that.
<nigel> .. We could change the note to say in addition that other processors might do something completely wrong.
<nigel> Glenn: Let me see if I can come up with some language like an advisory that doesn't say "should not" but takes the
<nigel> .. form of a recommendation to authors not to use it and see how people like that. How's that sound?
<nigel> Pierre: Sounds good, thank you for considering my comment.
<nigel> Glenn: Sure.
<nigel> SUMMARY: @skynavga to propose alternate wording advising non-use of textCombine in the context of ruby

[skynavga]

@palemieux @cconcolato see b92d37c

[cconcolato]

Not sure the second sentence is necessary, nor that the wording "is advised not to expect" is the best, but overall it's not wrong and does not hurt.

[skynavga]

@palemieux ping