15:02:10 RRSAgent has joined #tt 15:02:10 logging to https://www.w3.org/2018/02/08-tt-irc 15:02:12 RRSAgent, make logs public 15:02:12 Zakim has joined #tt 15:02:14 Meeting: Timed Text Working Group Teleconference 15:02:14 Date: 08 February 2018 15:04:08 cyril has joined #tt 15:04:23 tmichel has joined #tt 15:04:43 atai2 has joined #tt 15:05:10 scribe: nigel 15:05:22 Present: Andreas, Pierre, Cyril, Mike, Thierry, Nigel 15:05:25 mike has joined #tt 15:05:25 Chair: Nigel 15:05:31 Regrets: None 15:05:39 Log: https://www.w3.org/2018/02/08-tt-irc 15:05:45 Topic: This Meeting 15:06:42 Nigel: We've a packed agenda today so I'm hoping we can move through all the issues 15:06:53 .. rapidly with a minimum of technical discussion, so we have a clear view of the steps 15:07:03 .. to CR for all our specifications that we're working on by the end of the meeting. 15:07:50 .. We have lots to cover on TTML2, TTML1 and IMSC, primarily issues or pull requests 15:08:01 .. labelled "agenda" but also I think we need dispositions on all the open TTML2 issues 15:08:11 .. that need to be resolved before we request transition to CR. 15:08:23 Present+ Glenn 15:09:04 Nigel: Any other points to raise or other business? 15:09:22 .. One small AOB: the request for a joint meeting with APA - currently it looks like Feb 28 15:09:32 .. is the best day - please respond offline to my email. 15:09:49 group: [no other business] 15:11:02 Topic: TTML2 agenda issues 15:11:14 -> https://github.com/w3c/ttml2/labels/agenda TTML2 issues and pull requests labelled "agenda" 15:11:18 glenn has joined #tt 15:12:06 Topic: Fill in definition of tts:fontSelectionStrategy, add to schema, fix typo ttml2#632 (pull requests) 15:12:10 pal has joined #tt 15:13:04 github: https://github.com/w3c/ttml2/issues/371 15:13:24 tm has joined #tt 15:14:08 Nigel: I'm proposing to defer this as I noted earlier. 15:14:16 Glenn: I object to deferring it for the following reasons: 15:14:38 .. 1. It is not complex. The "auto" value is already implied by our processing model, silently. 15:14:58 .. It's been a long standing open area to flush out. As it turns out the way that "auto" is 15:15:10 .. technically defined is implementation dependent, but it does at least give some guidelines 15:15:23 .. as to what information constitutes the selection criteria, which we had not listed before 15:15:37 .. As for filling in the placeholder, we already had enumerated the style property as a token 15:16:06 .. in the list of vocabulary, and defined a feature for it. Not much was required to fill in the 15:16:20 .. gap to establish the two values. Nigel had even put in the derivation previously. 15:16:30 .. Really the only issue is whether or not we will have enough implementations to satisfy 15:16:46 .. exit criteria. We certainly have them for parsing the property (TTT already does it). The 15:16:58 .. semantics of auto are already supported in at least one implementation. I think it will 15:17:10 .. meet the CR exit criteria without any real issues. I don't see any issue with including it 15:17:24 .. and pulling it out now would prevent us from putting it in CR and offering it to industry to 15:17:43 .. implement. We could mark it as at risk - it is already marked as at risk. 15:17:51 s/k./k in this pull request. 15:17:55 tmichel__ has joined #tt 15:18:22 Andreas: I tend to agree with Nigel. People have to review deeply. There's some reference 15:18:34 .. to XSL-FO so if there is no strong demand for it then I would defer it. I think there has 15:18:38 .. not been enough review. 15:19:44 Nigel: For me this is not simple at all - reviewing in terms of XSL-FO and CSS is certainly 15:19:47 .. complex. 15:20:15 Glenn: The text in this pull request is not complex - if you try to understand XSL-FO and CSS then that is more complex. 15:20:31 .. I'm aware of XSL-FO implementations of character-by-character and it's extremely simple. 15:20:51 .. All the character value does is to turn off contextual characters and treat each character 15:21:03 .. individually. CSS adopts the same thing there. There's no danger in putting it in now. 15:21:12 q+ 15:21:48 Nigel: What is the use case for it? 15:22:11 Glenn: If you're using complex scripts and you have a list of fonts, e.g. "Monaco, UnicodeMS" 15:22:23 .. then Monaco as a font may not support all non-spacing marks and UnicodeMS is much 15:22:58 .. fuller and does support them. The "auto" semantic would fall back to the UnicodeMS font, 15:23:12 .. and might render it all in that font, but if the user wanted the base character in Monaco 15:23:27 .. and the generic glyphs for the combining characters from the UnicodeMS font. The auto 15:23:32 .. behaviour would not do that. 15:23:50 Nigel: Have any users ever asked for this? 15:24:02 Glenn: I'm aware of it in XSL-FO. We really need it for the auto semantics. If we did not 15:24:14 .. specify this feature then we have a gap in that we have not defined the implied automatic 15:24:30 .. semantics anywhere. If we did not do that then we would have to have a special semantics 15:24:59 .. subsection for font selection. 15:25:09 Nigel: This wasn't a problem in TTML1, and nobody has asked for it. 15:25:15 Glenn: Saying nothing doesn't address this. 15:25:45 .. It's been recognised for a long time that this is a missing piece of specification material, 15:25:50 .. going back to the change proposals. 15:25:57 ack atai2 15:26:47 Nigel: I think we have not enough time to add this detail now. 15:27:11 Glenn: If we cannot merge the pull request then let's see. 15:27:26 Andreas: What is the process if we cannot agree the pull request? 15:27:38 Nigel: I think if we cannot merge it we cannot publish a CR with an empty section in it, so 15:27:42 .. we have to defer by default. 15:28:40 q+ 15:28:49 ack atai2 15:28:52 ack atai 15:29:47 Glenn: There's no risk to the group since if a problem is found then the feature can be 15:29:55 .. removed post-CR, since it is marked as at risk. 15:29:58 ack pal 15:30:12 Pierre: There's risk to the group because this takes our time away from dealing with features 15:30:17 .. that users have asked for. 15:31:32 q+ 15:32:38 ack atai2 15:32:52 Andreas: Not sure if I'm being naive here but I assume that at risk features in a CR have 15:33:04 .. been reviewed carefully by the WG, and it is only at risk because there may not be enough 15:33:15 .. implementations for it. In this case it is not reviewed sufficiently, and there are concerns 15:33:32 .. so there are two options: Wait until we can resolve it, or defer it. We did not want to wait, 15:33:41 .. so I don't see where we have a lot of options other than to defer it. 15:35:07 Pierre: If the question is between deferring and missing the deadline then defer it. 15:35:15 Glenn: The group can say include it right now. 15:36:19 Pierre: I think this is a request to merge this without review. 15:36:28 Glenn: No, I'm not suggesting to thwart the 14 day cycle. 15:36:54 Pierre: In order to go to CR today we have to do that. 15:37:03 Nigel: We said in one week's time. 15:37:08 Pierre: That's fine. 15:37:21 .. I don't have a large stake in this, but if someone is going to object to going to CR 15:37:27 .. because of this then that's a problem for me. 15:37:54 tmichel has joined #tt 15:38:33 Nigel: My problem with this PR is that it is too late. 15:38:40 Glenn: I don't accept that. We're done when we're done. 15:38:52 Pierre: We have to be done in one more week. 15:39:18 .. If we merge this today then I will object. 15:39:51 Glenn: I will object to going to CR without this being included. 15:40:03 Nigel: At the moment I have an objection to merging as is, per my pull request review. 15:42:30 Glenn: You can record in the minutes that I'm objecting to removing this. 15:43:03 .. We either need to merge this or merge an alternative pull request to remove it. 15:43:40 Topic: Loosen coupling between item name="usesForced" and forced. ttml2#609 15:43:51 github: https://github.com/w3c/ttml2/issues/609 15:44:04 Glenn: Again here I object to removing it. I do not object to modifying the text to allow 15:44:15 .. it to cover other uses besides condition, which I think was the reason that this came up 15:44:27 .. in IMSC context, because IMSC 1.1 does not include condition (yet). 15:45:05 Pierre: I'm going to call for consensus to accept the pull request to remove it, because at 15:45:12 .. the moment it is not useful. 15:45:19 Andreas: I agree. 15:45:24 Nigel: I agree. 15:45:47 Cyril: Everything that makes it ambiguous for IMSC 1.1 in terms of forcedDisplay should be 15:46:04 .. cleaner. Glenn's proposal is to modify the usesForced parameter to make it clearer, and 15:46:12 .. I haven't seen the usage for it, so my preference is to remove it. 15:46:37 Glenn: The use case for this is to provide a top level way to determine if the document 15:46:47 .. uses forced or not and process it in a special way if it does uses forced. 15:46:59 Cyril: That's the problem. Pure metadata is maybe harmless, but if there is processing 15:47:03 .. associated then that's a problem. 15:47:12 Glenn: It's metadata but no processing is defined in the spec. 15:47:37 Pierre: My point is that will lead to intense confusion if some application uses it. 15:48:52 Nigel: No case was ever made for this named metadata item - it was added without discussion. 15:48:59 .. I'm not aware of anyone who has ever asked for it. 15:49:23 Cyril: I want to remove this. 15:49:44 Pierre: I propose to remove it and if Glenn wants to object to it then log that and take it forwards. 15:52:01 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. 15:53:46 Glenn: I would note that the WG has signed off on this feature previously in other WDs in 15:54:11 .. which this feature was included. Now the group is attempting to remove it without 15:54:24 .. identifying the feature as at risk, which can be done more easily. 15:56:24 Cyril: I propose a different option - the IMSC issue is about the feature being too broad. 15:57:00 .. I propose two features, one per named metadata item #usesForced and #altText. 15:57:10 .. Would that resolve it in IMSC1.1 Pierre? 15:57:23 Pierre: That would resolve it for me since I could prohibit it from IMSC 1.1. 15:57:40 Glenn: You want feature designators for individual named items? I could accept that. 15:59:25 Nigel: That would not resolve my issue, which is that prohibiting metadata items within 15:59:35 .. IMSC 1.1 that are harmless is too draconian. 16:00:23 Glenn: My alternative proposal is to make the change to usesForced so that it does not 16:01:56 .. require condition, so that it could be used in IMSC 1.1. 16:02:25 Nigel: The best option here is to remove the usesForced metadata item. 16:03:55 Pierre: I'd rather remove usesForced than have Nigel's objection. 16:04:02 Andreas: What was your objection Nigel? 16:04:30 Nigel: It is too draconian and if it is useful then it would force people who for some reason 16:04:53 .. do want to use it to use a different named metadata item, which is crazy. 16:05:02 Glenn: I agree that the prohibition is draconian. 16:05:18 Cyril: If we were to do nothing in TTML2 we could simply add a note to IMSC 1.1 that for 16:05:46 .. the avoidance of doubt, because condition is prohibited in IMSC 1.1 then the metadata 16:05:51 .. item is also prohibited. 16:06:12 Nigel: You could say it is "not applicable". 16:06:23 Glenn: I would say "it does not apply", which is different than prohibiting it. 16:06:34 .. Right now in TTML2 it is well defined and there's no technical problem. The issue is only 16:06:47 .. with IMSC, which could add clarifying semantics about the exclusion of condition, to say 16:06:59 .. that usesForced is predicated on condition and therefore does not apply. 16:07:13 Cyril: I would be okay with this pull request not being merged on the basis of that update 16:07:22 .. to IMSC 1.1, because it basically cannot be used. 16:07:37 Pierre: That's my conclusion as well, so I wanted to prohibit it in IMSC 1.1 to avoid any 16:07:41 .. confusion. 16:07:51 q+ 16:08:04 Cyril: The fact that it is prohibited is just a consequence not an extra syntactical constraint. 16:08:17 ack atai2 16:08:34 Andreas: Would that be acceptable for Nigel and Pierre to use a SHOULD? 16:08:43 Cyril: It cannot be a SHOULD, the document would just be wrong if it is used. 16:09:27 tm has joined #tt 16:09:28 Nigel: Actually using usesForced="false" would be fine. 16:10:21 .. You could have a document that does that and uses IMSC 1.1 usesForced semantics, 16:10:29 .. which would be technically correct but rather confusing. 16:11:06 Cyril: I would prohibit usesForced altogether, on the grounds that usesForced="false" cannot 16:11:17 .. be meaningfully used. 16:11:53 Glenn: I'm hearing a proposal to add #usesForced in TTML2 - I would have no problem with that. 16:12:07 .. I would also note that the description of usesForced needs an addition to say that absence 16:12:16 .. from the document does not imply anything. 16:12:59 Pierre: Would you be okay to re-evaluate your objection to prohibiting it? 16:13:35 Nigel: I need to think about that. I still think that the best thing is to note that it does not apply. 16:13:49 .. Are you going to abort processing because of the presence of metadata? 16:14:18 Pierre: For the sake of making sure people don't make mistakes we should prohibit it. 16:16:04 Glenn: By that argument you should prohibit all metadata in case it is misused. 16:16:21 Nigel: I think it is crazy to abort processing because of the presence of metadata, and 16:16:27 .. I don't think anyone would really want to do that. 16:17:27 Cyril: I don't think the proposal is to abort processing. 16:17:29 Nigel: I think it is. 16:17:40 Cyril: The document processor has the freedom to process invalid documents. 16:18:00 .. A validator though would detect this and say something is wrong. 16:18:40 Nigel: A warning would be sufficient. 16:18:50 Glenn: If you said "should not be present" then that would generate a warning. 16:20:20 Nigel: Pierre, mirroring your request earlier, would you reconsider your prohibition proposal? 16:20:48 Pierre: No presentation processor does validation, practically, in the field. 16:21:58 SUMMARY: There are a variety of options and we have no consensus right now. 16:22:04 SUMMARY: 1. Remove the feature from TTML2. 16:22:22 SUMMARY: 2. Generalise the description in TTML2 further than condition. 16:22:56 SUMMARY: 3. Define a feature designator in TTML2 called #metadataUsesForced (or something similar) 16:23:23 SUMMARY: 4. Do nothing in TTML2 and let IMSC add language to prohibit 16:23:54 SUMMARY: 4. Do nothing in TTML2 and let IMSC note the non-applicability, plus possibly recommend non-usage. 16:23:59 s/4/5 16:26:05 Topic: Make begin times relative to the document temporal coordinate space (#512) ttml2#616 (pull request) 16:26:17 Nigel: Please could someone review this pull request? 16:27:06 Glenn: It's on my list. 16:27:39 Topic: Improve animation value syntax (#383). ttml2#608 (pull request) 16:28:01 Cyril: If I understand correctly the change from string to [^;] is too wide. That looks editorial, right? 16:28:10 .. Glenn, can you change it to a less wide expression? 16:28:12 Glenn: No. 16:28:15 Cyril: Why? 16:28:47 Glenn: There's nothing broken - as per https://github.com/w3c/ttml2/pull/608#discussion_r166958259 16:29:22 .. it is irrelevant - this applies to delimiters and control characters. If it passes XML parsing 16:29:28 .. then it's okay. 16:29:34 Nigel: That's new information, and useful. OK. 16:29:54 Glenn: If we had a DOM then technically it could be difficult to serialise, but it could still be escaped. 16:31:51 Cyril: I'm approving this. 16:31:54 Nigel: Me too. 16:32:48 Topic: consider removing recommendations that do not appear to address a technical problem imsc#329 16:32:53 github: https://github.com/w3c/imsc/issues/329 16:33:04 Mike: I ran across the spec, and there were two SHOULD provisions about authoring and 16:33:15 .. they don't seem to solve any problem and put unnecessary constraints on the authoring, 16:33:24 .. at least at the recommendation level, and that seems weird to me. 16:34:37 Nigel: I believe the cellResolution SHOULD is because we did not want to rely on default values. 16:34:47 Mike: Then lots of other default values need additional text. 16:35:01 Andreas: In this case the cell resolution is used even when the c unit is not used. 16:35:36 Glenn: I suspect it was done by analogy to pixel, where there is no default extent on the root. 16:35:45 .. In this case I agree it is unnecessarily overconstrained. 16:36:54 Pierre: It traces history way back including EBU-TT-D. 16:38:04 Andreas: I see both sides - especially on cellResolution a general recommendation to set it 16:38:09 .. can make sense. 16:38:19 Pierre: The reason it was put in there was because at some point in an early EBU-TT-D draft 16:38:22 .. it was mandatory. 16:38:28 Mike: But it is not now. 16:38:49 Pierre: There's a desire for EBU-TT-D to be a subset. That meant we could not prohibit it in IMSC1. 16:39:08 Nigel: Can I propose to remove this cellResolution recommendation? 16:39:23 Pierre: No objection for IMSC 1.1. We tried to minimise changes to IMSC 1.0.1 and if we 16:39:31 .. change it there then some validators will complain wrongly. 16:39:50 Andreas: I would also go with that. There have been liaisons exchanged with other groups 16:40:04 .. and I'm not sure about the other standards organisations' responses to changing 1.0.1. 16:40:12 .. It could be viewed as a substantive edit. 16:40:57 Mike: I don't feel strongly about acting on this in 1.0.1. 16:41:58 RESOLUTION: Remove the recommendation to include cellResolution in 1.1 16:42:13 Mike: Moving on to the second one about time expressions using the same syntax. 16:42:36 .. There are good authoring reasons not to conform with this. 16:44:13 Andreas: I made a comment also, agreeing with this. 16:44:30 Nigel: I can't recall why this is present. 16:44:49 Pierre: This came from CFF-TT - I can only assume that it was an attempt to stop authors 16:45:02 .. from making things more complicated. I'm not aware of any technical reason for this constraint. 16:45:13 Mike: I do not recall anything either. 16:45:17 Pierre: I think it can be removed. 16:46:09 RESOLUTION: Remove the recommendation to use the same time expression syntax throughout a document in 1.1. 16:46:16 Mike: I'll change the label to 1.1. 16:46:21 Pierre: I'll prepare a pull request. 16:46:57 Topic: Feedback on HDR compositing ttml2#400 16:47:03 github: https://github.com/w3c/ttml2/issues/400 16:48:02 Nigel: This is just to check there are no comments on the draft response prepared by Pierre. 16:48:29 .. [time passes] That's a no. I'll go ahead and send this. Thank you for preparing that, @palemieux. 16:48:38 github-bot, end topic 16:49:16 Topic: Next step to TTML2 CR 16:49:29 Cyril: We have some pull requests that are blocking. I also count 13 open issues. 16:49:30 https://github.com/w3c/ttml2/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22pr+open%22+-label%3A%22pr+merged%22+-label%3A%22no+change%22+-milestone%3A%22Post+CR1%22+-label%3Aeditorial+-label%3Attml.next 16:49:51 Cyril: this removes everything post-CR1, everything editorial, everything ttml.next, everything 16:50:03 .. with a pr open or merged, and there are 13 remaining without pull requests. How are 16:50:21 .. we going to proceed with these. If we open a pull request today then we will not have 16:50:40 .. a CR ready for two more weeks, right? 16:50:42 Nigel: Correct. 16:51:11 Cyril: I would like to defer all these issues. Can we defer them to ttml.next or is there any 16:51:15 .. pressing issue to be handled now. 16:52:05 Nigel: I would exclude the discussed and agreed ones. 16:52:23 Cyril: We will have to create a pull request anyway for those, like #280. 16:52:35 Nigel: Correct, but we need to resolve it anyway because it is a wide review comment. 16:52:53 Cyril: Glenn, can we defer those, or some of them, or what is the status? 16:53:03 Glenn: I would like to have until the weekend to make as much progress on these as I can and 16:53:17 .. by Sunday if I have not dealt with any of them or asked for help and got it then I will 16:53:26 .. propose some action that might involve deferral. 16:53:36 .. #365 and #366 are about three quarters done with a pull request. 16:53:44 .. The sideways issue should easily be taken care of. 16:54:01 .. Looking at each of these individually, some of them involve things that are broken or 16:54:22 .. underspecified, like #495, so things in the broken category, or potentially fatally 16:54:34 .. underspecified, should be dealt with sooner rather than later. The question is does any 16:54:48 .. of them require adding a new feature. One thing I need to do also is make a final pass 16:55:03 .. at reviewing the feature designators with respect to the new features we've added. 16:55:11 .. Someone else could do that, it would be helpful. 16:55:20 .. #379 could probably be deferred. 16:55:27 Cyril: Can we do it now? 16:56:16 Glenn: The intent of #379 is more advisory than a semantic change, just adding the 16:56:23 .. qualifiers to the profile document. 16:56:27 Nigel: That can happen after CR. 16:56:32 Glenn: I agree. 16:56:51 Nigel: I've changed the milestone. 16:57:45 https://github.com/w3c/ttml2/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+-label%3A%22pr+merged%22+-label%3A%22pr+open%22+-milestone%3A%22post+cr1%22+-label%3Awr-for-disposition-action 16:59:25 Cyril: If we use Sunday, which is the 11th, then the earliest interpretation is 10 days later, 17:00:18 .. which is 21st, being the earliest we could go to CR. That means any changes would need to be made by the 11th. 17:00:29 Nigel: We already said this deadline was the 1st - we can't just keep moving the deadline. 17:00:42 Pierre: We should just defer to another CR. 17:01:19 Glenn: That would create more delay. I would be happy to manage the 22nd. 17:01:39 Nigel: I could accept that, but the strong view of the group earlier was not to slip that late. 17:01:46 Cyril: I propose a call on Monday to review where we are up to. 17:01:50 Pierre: Works for me. 17:01:57 Glenn: I could do the same time on Monday. 17:02:24 Nigel: I can't do that - I have a prior commitment. 17:02:31 Cyril: Tuesday? 17:02:35 Nigel: I could do Tuesday 17:02:38 Glenn: Fine with me. 17:02:45 Pierre: I can only do one hour on Tuesday. 17:03:33 Glenn: I could do that. 17:03:59 Nigel: Okay, I'll schedule that for 10am Boston on the 13th. 17:04:07 Andreas: I will not be able to make it but it is fine if you go ahead. 17:04:46 Cyril: The goal is to review the PRs that have been opened and mark all issues with no pull request 17:04:49 .. as deferred. 17:05:00 Glenn: I would call it 'final triage', and make a decision on that basis. 17:05:40 Nigel: I or someone else could just go through the issues without pull requests on Monday 17:05:43 .. and defer them. 17:05:47 Glenn: Can I do that on Sunday? 17:05:52 Nigel: Yes! 17:06:01 .. We won't have an additional meeting on Tuesday then. 17:06:14 .. I'll send an email on Monday asking for consensus to defer all the remaining issues. 17:06:26 Cyril: Then on the Thursday call we only have to discuss existing pull requests. 17:07:54 Nigel: I would also ask that active members positively approve everything that they're okay with 17:08:00 .. to offset the risk of a later objection. 17:09:01 Glenn: Also please consider carefully if you're going to request a change based on purely 17:09:07 .. editorial issues. 17:09:20 Nigel: We're out of time, thank you everyone. [adjourns meeting] 17:09:26 rrsagent, make minutes 17:09:26 I have made the request to generate https://www.w3.org/2018/02/08-tt-minutes.html nigel 17:09:57 github-bot, end topic 17:13:06 scribeOptions: -final -noEmbedDiagnostics 17:13:09 rrsagent, make minutes 17:13:09 I have made the request to generate https://www.w3.org/2018/02/08-tt-minutes.html nigel 17:33:26 nigel has joined #tt 18:09:37 Zakim has left #tt