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

[skynavga]

Closes #978.

[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 https://github.com/w3c/ttml2/pull/1171/commits/838df594f443481cc2160b447beb5647bfa9926e

[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 https://github.com/w3c/ttml2/pull/1171/commits/5a6487a9a8949841c6000671c8d4e6a2b1c48902. 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/w3c/ttml2/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 https://github.com/w3c/ttml2/pull/1171/commits/b92d37ce8619e6a05a6b37cdda90a16dc95cc665

[skynavga]

@palemieux ping