nigel has changed the topic to: TTWG weekly webex. Today 1500 UTC. Agenda for 2019-11-07: https://github.com/w3c/ttwg/issues/77
Nigel: Hi everyone, today we have 3 TTML2 issues/pull requests to discuss.
… Any other business?
group: [no other business]
Nigel: I see Glenn just added a comment to the agenda asking to discuss #1128 first.
github: https://github.com/w3c/ttml2/issues/1128
Nigel: Looks like there's a collective desire for the image in the example and the text to match each other and show something useful?
Cyril: Yes. I don't mind the text being vague, but at the moment it is wrong because it isn't showing what is happening at all.
Glenn: I disagree with that.
Cyril: It only talks about half-width variants but none are selected in the example.
Glenn: It does have them.
… The AB34 on the right side are half width variants.
Cyril: Unless the image has changed they are quarter width, right?
Nigel: The "AB34" look like they're in one EM square width and heightwise.
Cyril: Yes, so they're not half width variants but quarter width.
Glenn: [thinks] Maybe we should remove the term "half width" entirely.
Cyril: Yes, that's one option.
Glenn: That I think is problematic. I could go back and remove that.
Cyril: Great, that's all I'm asking.
Glenn: Would you be ok with that Pierre?
Pierre: I'm happy with whatever Cyril is happy with!
SUMMARY: @skynavga to remove reference to "half width" for this example.
github: https://github.com/w3c/ttml2/pull/1171
Glenn: There appears to be a difference of opinion between myself and Pierre.
… The intent of this was basically to say that in the context of ruby text that text combination has no semantics defined,
… so I had proposed a note that says this version of TTML does not define any semantics for text combine in the context
… of ruby text content and added that presentation processors may ignore text combine (treat as None) in the context
… of ruby text. Pierre doesn't seem to like the second part but I think it's a logical consequence of the first sentence.
Pierre: I'm going to repeat myself, but the second sentence specifies a permission and therefore a semantic so it has
… to be removed.
Glenn: It is in a note so is not normative.
Pierre: Equally it can be removed then.
Cyril: Is it the use of "may" that creates confusion?
Pierre: Yes, absolutely. I think it is true that there are no semantics, so there are none, period.
Glenn: We use "may" in notes.
Pierre: If there is no semantic there should be no suggestion one way or another.
Cyril: What is the intent, to say "don't use them together because you won't get interop"?
… Or that some implementations may do it right and others may not but if you are using conformant implementations
… then you can still use it.
Glenn: Is it the problem that it looks like conformance language.
Pierre: That is not my problem, although it is throughout TTML2, I've said before.
Nigel: Could we water down the second sentence to say "For example, ... could ignore"?
Pierre: And add a contrary example too.
Glenn: either would work for me.
Cyril: Me too, it's okay.
Glenn: We have "for example" elsewhere in notes.
Cyril: That means implementers could expect to encounter content with this.
Glenn: I wouldn't say should expect but it is possible.
Cyril: Is there a defined behaviour?
Glenn: This is there to put authors on notice that they should not expect a particular behaviour.
Cyril: So we should say do not use it.
Glenn: That's going too far.
Pierre: I agree with Cyril, the intent is to warn authors not to use it because the implementation is undefined.
Glenn: We cannot say "should not be used" in a note - we don't do it in a note.
… In many cases we give fair warning to readers that it is inadvisable.
… This is how we do it.
Pierre: Here it is more than that, something could happen, it might not be ignore.
Nigel: We're agreeing about the reality of what is specified, just discussing what the best advice is to readers.
Cyril: Are we agreed to advise people not to use?
… If we agree that because this feature is not specified people should not rely on it or use it because they might get
… any behaviour? If so then we can work on the text.
Glenn: Generally we don't say in TTML that authors should use or not use something. That's a profile question.
Cyril: Do you agree on the intent here, that "unspecified behaviour" means anything could happen?
Glenn: I agree, we don't want users to use something that is undefined.
Cyril: I agree with Pierre that if we hint that it will be ignored people might rely on that.
… We could change the note to say in addition that other processors might do something completely wrong.
Glenn: Let me see if I can come up with some language like an advisory that doesn't say "should not" but takes the
… form of a recommendation to authors not to use it and see how people like that. How's that sound?
Pierre: Sounds good, thank you for considering my comment.
Glenn: Sure.
SUMMARY: @skynavga to propose alternate wording advising non-use of textCombine in the context of ruby
github: https://github.com/w3c/ttml2/pull/1179
Glenn: Before we start this, just to point out that this and the next issue today are marked for 3rd Ed so if we keep
… them there then we don't have to deal with them right now.
Nigel: Thank you, that's useful. If we have agreement now we can implement it, otherwise we don't need to stress too
… much about it.
Glenn: To summarise the situation, part of this was about prose to do with anonymous span concerning ordering
… that was possibly vague and we need to be clear about ordering of rules.
… There are two ways to do this. One is to add text directly about ordering like we have in some places,
… or prescribe a general rule about ordered lists and I chose to take the latter route because I realise that everywhere
… we have ordered lists in the text, and where the underlying XML document uses the `<olist>` syntax and it was
… used to define procedural steps it was always intended to be ordered sequentially and we could apply generic text.
… After analysing all the document I found that everywhere that the ordered lists were used for procedures it was
… always intended to be sequential, but that in a number of places where it was enumerating cases that were not
… procedures or steps that no order was implied, i.e. an unordered list of bullets could be used but I had used olist
… in order to allow referring to specific cases as opposed to steps. For example in the list of criteria under
… processor or document conformance we have items that are listed 1 through 3 and so forth that could have been
… bulletted items but then I would have no way to refer to each criterion as a numbered item.
… My proposal was to have a rule that said wherever ordered lists appear in procedures as ordered steps then they
… are always in the indicated order and we can take out any text in the inline prose that talks about it being ordered
… and use the general rule instead. But Nigel I think you have a slightly different opinion that you want it to be defined
… inline instead.
Nigel: Yes, I want to keep the current approach so as to avoid promoting use of unordered lists that lead to a list
… of steps that we cannot then reference. It's useful to know that there's already a case there.
Pierre: My preference is to make fewer changes and just add the "this is an ordered list" text to the one specific list
… that gave rise to the issue and do nothing else. If that's not acceptable then defer this.
Glenn: I was just counting the number of places where there is an ordered list missing the language of ordered steps,
… 31, and the number that could be unordered lists, 10. There's a case that the default rule could apply to ordered
… lists being ordered always, numerically. One option would be to change everything to unordered lists that are criteria
… or cases which would remove the ability to refer to specific cases or criteria unless we name them, which is somewhat
… of a negative.
Nigel: It's a blocker for me.
Glenn: Maybe the best thing is to do as Pierre suggests, to handle this one case specifically by adding the language
… about "ordered" and move this general issue into 3rd Edition.
… Then we can deal with that later.
Cyril: I would like this last proposal, we should not do major changes at this stage. We should not change parts that
… are not broken because we think it would be better.
Glenn: I'm fine with that, it would deal with the immediate issue about span processing.
Nigel: Works for me.
Glenn: OK I will create a new issue regarding the ordering and point at this and create a new PR dealing with just the
… original issue. OK?
Nigel: Any objections?
group: [no]
Glenn: And I'll deal with the original issue in 2nd Ed CR.
SUMMARY: @skynavga to add ordering language to deal with original scope of issue, and raise new issue for general ordering of steps, targeted at 3rd Ed.
github: https://github.com/w3c/ttml2/pull/1173
Nigel: We seem to be trying to escape backslashes here without defining an escape mechanism.
… Perhaps we don't need to do anything here?
Glenn: In TTML2 we introduced something absent from TTML1. In `<quoted-string>` in TTML2 we introduce an
… escaping mechanism.
Nigel: We invoke a backslash in the syntax there.
Glenn: If you look at TTML1 3rd Ed ... It's there.
Nigel: TTML1 3rd Ed has it under `<familyName>`
Glenn: [looks] it's in TTML1 2nd Ed too, maybe I didn't look well enough and it's in 1st Ed too!
… It wasn't in 1st Ed, we added it in 2nd Ed. So it's been around a while, but not in the very beginning. We didn't use it
… in any of TTML1 in the syntax descriptions, we didn't use the double backquote.
… When we normalised the syntax in TTML2 we changed all the literals to string literals; we had used character literals
… with single quotes in TTML1 2nd and 3rd Edition.
Nigel: Why don't we do something really simple here, to say where we use `\\` what we mean is a single backslash?
… The PR has a "for example" but I'm proposing making it not an example, but the rule.
Glenn: Problem is you could escape quotation marks.
Nigel: But we don't
Glenn: But we could
Nigel: But we don't
Glenn: The quotation marks are only significant only after escape processing should ...
Nigel: But it's our choice in the spec if we use that anywhere and I don't believe we do, so we don't need this.
Glenn: Ah I see what you're saying. Are you sure we don't?
Nigel: It's worth checking
Glenn: You're correct we don't at present do that.
Nigel: So the only thing we need to define is that \\ means \ in the document content.
Glenn: Just remove "after escape processing"?
Nigel: Also make the note in 2190-2192 in this PR normal spec text and remove "For example,"
Glenn: Oh I see what you're saying.
Pierre: If I understand, instead of making a blanket statement about escaping, merely state this specific case?
Nigel: Yes
Pierre: I agree with that, it's the simplest and safest approach.
Glenn: OK, regarding lines 2188 and 2189, shall I revert those to the original text?
Nigel: I would say so, yes.
Glenn: Ok so revert those and then change 2190-2193 to normative text and remove the "for example" and that's it.
Nigel: Yes
Glenn: Sounds good, I can do that. I'll change this to 2nd Ed CR milestone.
Nigel: Brilliant, thank you.
SUMMARY: @skynavga to make changes as minuted above.
Pierre: Do you know what is happening with IMSC 1.2 FPWD?
Nigel: I'm not actually sure, I haven't managed to chase that up yet.
Pierre: Let me know how I can help, I'm getting a little concerned that nothing happened this week.
Nigel: Understood.
… For today, we're out of agenda and out of time, so I'll adjourn. Same time next week unless there's a big pile of
… agenda requests in which case we can extend to 2 hours as per normal operation. Thanks for getting through
… so much today everyone. [adjourns meeting]