15:01:22 RRSAgent has joined #tt 15:01:22 logging to https://www.w3.org/2022/09/29-tt-irc 15:01:24 RRSAgent, make logs Public 15:01:25 Meeting: Timed Text Working Group Teleconference 15:04:20 pal has joined #tt 15:04:50 Agenda: https://github.com/w3c/ttwg/issues/228 15:05:13 Topic: This meeting 15:05:18 scribe: nigel 15:05:21 Chair: Gary, Nigel 15:05:36 Gary: Using Teams for the TPAC meetings was good 15:05:39 Nigel: We can switch! 15:05:43 Gary: I wouldn't be opposed. 15:05:49 Nigel: Let's do it. 15:06:09 Gary: I can;t do the next one, in two weeks, it coincides with Demuxed. 15:06:25 present+ 15:06:30 Present: Cyril, Gary, Nigel, Pierre 15:06:59 Previous meeting: https://www.w3.org/2022/09/16-tt-minutes.html 15:07:46 Nigel: Agenda for today is: follow-up opportunity from TPAC, DAPT issues, Rechartering status update 15:07:56 .. Anything else for the agenda, or points to make sure we cover? 15:08:43 Pierre: There's an outstanding pull request on IMSC-HRM I'd like to encourage folks to review it. 15:08:56 .. Open 13 days ago, discussed in last meeting. I'd like to merge it unless there are significant concerns. 15:09:05 Nigel: Thank you for the reminder. 15:09:22 .. Sounds like there's nothing more to say on that. 15:09:33 Pierre: I plan to merge it if there are no concerns - it addresses a real issue. 15:09:36 Nigel: Thanks. 15:09:48 Present+ Atsushi 15:10:09 Topic: TPAC follow-up 15:10:29 Nigel: Nothing specific from me - I just want to give the opportunity to discuss if there's anything on your mind. 15:11:22 Topic: DAPT issues 15:11:43 -> https://github.com/w3c/dapt/issues?q=is%3Aopen+is%3Aissue+label%3Aagenda DAPT Issues marked for the agenda 15:11:56 cyril has joined #tt 15:12:43 Subtopic: Should we allow inheritance of xml:lang or require it to be set explicitly? w3c/dapt#62 15:12:45 https://github.com/w3c/dapt/issues/62 : Should we allow inheritance of xml:lang or require it to be set explicitly? 15:14:12 Nigel: The issue here is that the current spec text requires an explicit xml:lang on tt and every p. 15:14:31 Cyril: Also it's value must not be empty 15:14:44 .. Some background: 15:14:52 .. The use cases are: 15:15:07 .. 1. Transcription of a show with multiple languages - it's important to be able to annotate the actual language 15:15:12 .. per script event. 15:15:26 .. 2. When you have, for a given event, after it has been translated, you want to preserve the original 15:15:43 .. language. You can have 2 or more languages per event, one being the original, the other being the translation. 15:15:52 .. I don't have a strong preference, we could live with inheritance. 15:16:05 .. The document would be more regular if there is always an xml:lang on every p. 15:16:20 .. Inheritance of xml:lang is not complex. It's not like CSS properties where you need a computed value. 15:16:29 .. No strong preference, just in the spirit of making it simple. 15:16:41 .. Are you concerned about the redundancy, the size? 15:16:55 Nigel: Yes, somewhat, especially in the AD case. 15:18:14 .. But generally I think the formal requirement is that there is a non-empty computed xml:lang on all 15:18:33 .. character content. There can be a suggestion of a way of doing it, but not the formal requirement to have 15:18:36 .. it on every p element. 15:18:51 .. Especially early in the workflow, it may well be that the original language text is all in the document's 15:19:01 .. xml:lang and adding it everywhere is unnecessary. 15:19:06 Cyril: I agree. 15:19:20 .. I think you're happy to say that there shall be a non-empty computed xml:lang on all character content, 15:19:33 .. and either a recommendation or a permission to put it on every p, something like that? 15:19:37 Nigel: Yes. 15:19:45 Cyril: Fine with that. 15:19:56 Nigel: Any other views? 15:20:45 SUMMARY: Require non-empty computed xml:lang on all character content, permit/recommend having it on every p element. 15:20:58 Nigel: It could also be on span elements, by the way, in principle. 15:21:10 Cyril: I would say the recommendation should be to split per language. 15:21:21 .. But you may have one Spanish word in an English sentence, say, you may want to tag that. 15:21:41 Nigel: Exactly. I'm in favour of flexibility unless a strong reason to constrain. 15:22:10 Cyril: So you or me will prepare a pull request? 15:22:15 Nigel: Yes, others welcome too! 15:22:39 Subtopic: Do we want to allow inline styles? w3c/dapt#60 15:22:40 https://github.com/w3c/dapt/issues/60 : Do we want to allow inline styles? 15:23:07 Github: https://github.com/w3c/dapt/issues/62 15:23:14 github-bot, end topic 15:23:22 Github: https://github.com/w3c/dapt/issues/62 15:24:09 Subtopic: Do we want to allow inline styles? w3c/dapt#60 15:24:11 https://github.com/w3c/dapt/issues/60 : Do we want to allow inline styles? 15:25:37 Nigel: Is there any reason to disallow inline styles? 15:25:52 Cyril: First thought I had was about Japanese - does it make sense to have Ruby in AD or Dubbing Scripts, 15:26:03 .. but if you want it then it has to be on the span level. 15:26:15 .. I think I would be silent here and let implementations do what they want. 15:26:30 .. It's out of scope of our spec. If you have a processor that doesn't use styles it will ignore them. 15:26:44 .. If you want to make subtitle files then it's a good idea to allow them. 15:26:51 Nigel: Yes, they're permitted in IMSC. 15:26:55 Cyril: Yes 15:27:03 .. Happy to see if you have any wording you want to add. 15:27:27 Nigel: One other use case: for audio mixing, we expect to use the animate element and that effectively 15:27:44 .. sets and varies the values of inline style attributes, in this case things like tta:gain and tta:pan. 15:27:56 .. So from that point of view it would be complex to prohibit inline styling. 15:28:13 Cyril: Are they considered inline if they're only on animate? 15:28:18 Nigel: I haven't checked that in detail. 15:28:31 Cyril: On the principle I would prefer to allow it by being silent. I'm happy to see wording if you 15:28:35 .. want to be more explicit about it. 15:28:39 Nigel: OK 15:28:57 .. I think it's a note alongside the other text on styling. 15:29:21 .. I have started work on a pull request for styling, for issue 29, so I'll include this in that. 15:29:40 SUMMARY: Permit inline styling 15:29:45 github-bot, end topic 15:29:57 github-bot, end subtopic 15:29:57 nigel, Sorry, I don't understand that command. Try 'help'. 15:30:08 github-bot, help 15:30:08 nigel, The commands I understand are: 15:30:08 help - Send this message. 15:30:08 intro - Send a message describing what I do. 15:30:09 status - Send a message with current bot status. 15:30:09 bye - Leave the channel. (You can /invite me back.) 15:30:09 end topic - End the current topic without starting a new one. 15:30:10 reboot - Make me leave the server and exit. If properly configured, I will then update myself and return. 15:30:20 github-bot, status 15:30:20 nigel, This is wgmeeting_github_ircbot version 0.4.8, compiled from 722bc7731cddbfd8ced5e57f7190a28d6a844a31, which is probably in the repository at https://github.com/dbaron/wgmeeting-github-ircbot/ 15:30:20 I currently have data for the following channels: 15:30:20 #aria-apg (no topic data buffered) 15:30:21 #css (no topic data buffered) 15:30:21 #tt (no topic data buffered) 15:30:21 #webdriver (no topic data buffered) 15:31:03 Topic: Consider timing syntax constraints w3c/dapt#59 15:31:04 https://github.com/w3c/dapt/issues/59 : Consider timing syntax constraints 15:31:53 Nigel: In particular this one is about prohibiting use of the dur attribute 15:32:24 .. At the moment we say begin and end attributes must be present. 15:32:55 .. One issue is about adaptation, where @btsimonh suggested omitting end attributes within spans, 15:33:07 .. but allowing begin attributes as a mechanism for specifying word timings. 15:33:44 .. So two questions: 1, the attributes we permit, and 2. the syntax of time expressions themselves. 15:33:54 .. I think we want to say nothing about time expressions? 15:34:16 .. I think the only time constraint is that the timebase must be media. 15:34:31 Cyril: This is the type of question where we need feedback from implementers. 15:34:41 .. Do they need all the options? 15:34:51 .. I don't have a strong opinion either way. 15:34:58 .. The choice of begin and end was for simplicity. 15:35:19 Pierre: Even more obscure, if timeContainer is seq or par. That one is pretty safe to forbid I think, 15:35:32 .. at least to specify that it will always be seq. 15:35:39 .. (by prohibiting it from being specified) 15:36:00 s/seq/par 15:36:10 Nigel: However there's a use case for seq here! 15:36:47 Cyril: There's a difference between timing at event level, where only one is active at any time. 15:36:57 Nigel: I thought we need to handle multiple speakers at the same time? 15:37:02 Cyril: Oh yes, forget that. 15:37:35 Nigel: My AD use case is to slightly simplify the expression of "fade, mix AD in, fade back" as three 15:37:51 .. always sequential things, where the begin of each is the end of the previous. 15:38:21 .. However I've never done it that way, I've always explicitly set the times using par. 15:38:33 .. I'm happy to stick with par unless we hear otherwise. 15:38:48 Cyril: Let's do that. If we want to map to IMSC, seq is not allowed, right? 15:38:55 Pierre: No, it is allowed in IMSC. 15:39:00 .. I'll check 15:39:17 .. Yes, pretty sure there's no restriction. 15:39:58 Nigel: The advantage of prohibiting it is simpler implementation, 15:40:24 .. the con is it might prevent some authoring cases. 15:40:46 Pierre: I think they're always mappable one to the other, so simplifying parsing marginally might be good. 15:41:07 .. I suspect that the first writers of IMSC would have forbidden seq had they been aware of timeContainer. 15:41:37 Nigel: I propose to mark timeContainer as prohibited, 15:41:42 Pierre: I would not constrain dur 15:41:50 Nigel: Yes, I'm a bit concerned about that. 15:41:59 Pierre: It's not worth the risk given the complexity of implementation. 15:42:09 Nigel: So I propose we permit dur. 15:42:28 .. And then for the time expression syntax, I propose we leave it open to anything in TTML, but 15:42:58 .. add an editorial note requesting specific feedback on this point, to highlight the question during wide review. 15:43:20 Cyril: IMSC has no restrictions on time expressions? 15:43:34 Pierre: No, I think it had a recommendation of using begin and end but that is not present now. 15:43:53 .. The good news is there are multiple implementations of temporal syntax computation/resolution 15:43:57 .. so the risk there is not great. 15:44:11 .. One way to limit the risk is to provide really good examples and templates. 15:44:20 Cyril: Do we really need wallclock time? 15:44:31 Pierre: That's a different question - IMSC only does media time. 15:44:49 Cyril: No, my question was ambiguous. The definition of time expression includes wallclock time. 15:45:30 Pierre: In IMSC there are no restrictions. All the options are permitted. Oh, but not #time-wall-clock, that's prohibited. 15:45:58 Cyril: I want to prohibit it here too. 15:46:06 Nigel: I have no use case for it, happy to prohibit it. 15:47:02 Cyril: What about timebase? Media only? 15:47:20 Nigel: Yes, I would say so. 15:47:34 .. I think I proposed it somewhere, very happy to confirm. 15:47:50 Cyril: There's one issue here, which is #45, about synchronisation. 15:48:00 Nigel: Yes, that's where I proposed it. 15:48:14 Cyril: I think we did agree, but did not capture it clearly. It's not implemented in the spec. 15:48:19 Nigel: OK we'd better do that! 15:48:45 Cyril: Actually in the feature list constraints it does do this, but it's not in the text. 15:49:07 Nigel: We still need to review all those dispositions. Formally it's there, agreed. 15:51:20 SUMMARY: timebase must be media, no wallclock, no timeContainer, permit dur, don't be dogmatic about presence of begin and end everywhere 15:51:30 Cyril: Do we need begin somewhere though? 15:51:49 Nigel: In the extreme case of a short clip it may be only occupied with one utterance for the entire duration, 15:51:58 .. so it would not add anything to specify begin and end. 15:52:26 Topic: Rechartering status update 15:53:36 Nigel: At end of TPAC Atsushi was preparing the team report for the FO Council experiment. 15:53:50 .. Since then there has been a bit of chatter on the charter draft pull request from Apple, but I don't 15:54:00 .. think it's gone anywhere particularly helpful. The PR was rebased. 15:54:17 .. Atsushi, how are you getting on, do you need anything from us? 15:54:35 Atsushi: It's finished, and a call for participation for the FO Council was opened from this Monday 15:54:45 .. for 2.5 weeks. FO Council may start in mid October. 15:54:58 .. Before that, the team report will be shared with the TTWG and the formal objector, to get any comments. 15:55:03 .. That's the current status. 15:55:27 Nigel: That call for participation was this Monday just gone? 15:55:30 Atsushi: Yes 15:55:51 Nigel: Any questions from anyone on this? 15:56:02 Group: No questions. 15:56:43 Topic: Rather than using ttm:role for script type, define new attribute w3c/dapt#54 15:56:45 https://github.com/w3c/dapt/issues/54 : Rather than using ttm:role for script type, define new attribute 15:56:54 Github: https://github.com/w3c/dapt/issues/54 15:57:26 Nigel: Suggestion at the moment is to define a new attribute in daptm: namespace for the script type. 15:57:30 .. Other alternatives are: 15:57:38 .. 1. Add values to ttm:role via registry 15:57:57 .. 2. Use some other existing metadata such as something defined by EBU in ebuttm: namespace 15:58:28 .. It occurred to me that the path of least resistance is to define a new attribute. 15:58:51 .. Then there's the question of future flexibility, where I suggested we define the value space in a registry. 15:59:15 .. Do we have semantic or syntactic constraints on the document based on script type? 15:59:25 Cyril: Yes, for example Character is mandatory when dubbing. 15:59:34 .. So depending on the script type value you may require this or that. 16:00:08 .. The more I think of it the more I prefer a specific attribute rather than making implementers worry about ttm:role and its other possible values. 16:00:17 .. This way we isolate/limit the work to be done. 16:00:30 .. My take on registry is only introduce it if we need to in the future. 16:00:50 .. It would only be editorial? 16:00:59 Nigel: It's possible to have registry tables embedded in Recs 16:01:04 Cyril: I would prefer to avoid that for now. 16:01:10 Nigel: That's fine for me, let's do that. 16:01:34 SUMMARY: Define new script type attribute and don't make it a registry 16:01:38 Topic: Meeting close 16:01:45 https://www.w3.org/2002/09/wbs/35125/tpac2022-Hybrid/ 16:02:23 Atsushi: For AOB, please feed back on the WBS survey about hybrid TPAC, link above. 16:02:46 Cyril: I did actually submit it, we received it on the last day, the Friday 16:02:51 Nigel: I didn't notice it, will look. Thanks. 16:03:10 Nigel: We're over time for today, let's adjourn, thanks all. Next meeting is in two weeks. 16:03:39 .. If we need more frequent meetings while we are doing a lot of editorial work we can increase the frequency. 16:03:50 Cyril: That might work in November - October is very busy with other events. 16:03:59 Nigel: Let's bear that in mind as a possibility. 16:04:17 Pierre: If it gets to the point where there are a few significant issues, we can plan an in-person meeting 16:04:20 .. if that would help. 16:04:27 .. I mention it now because it takes more planning. 16:04:36 .. It's mostly DAPT folks - the rest we can deal with remotely. 16:04:51 Nigel: Thanks, that's a good place to end. [adjourns meeting] 16:05:11 rrsagent, make minutes 16:05:11 I have made the request to generate https://www.w3.org/2022/09/29-tt-minutes.html nigel 16:12:31 s/Topic: Consider/Subtopic: Consider 16:18:38 s/github-bot, help// 16:18:46 s/github-bot, status// 16:18:58 s/nigel, Sorry, I don't understand that command. Try 'help'.// 16:19:06 s/nigel, The commands I understand are:// 16:19:13 s/help - Send this message.// 16:19:20 s/intro - Send a message describing what I do.// 16:20:26 s/status - Send a message with current bot status.// 16:20:32 s/status - Send a message with current bot status.// 16:20:39 s/end topic - End the current topic without starting a new one.// 16:20:45 s/reboot - Make me leave the server and exit. If properly configured, I will then update myself and return.// 16:20:55 s|nigel, This is wgmeeting_github_ircbot version 0.4.8, compiled from 722bc7731cddbfd8ced5e57f7190a28d6a844a31, which is probably in the repository at https://github.com/dbaron/wgmeeting-github-ircbot/|| 16:21:05 s/I currently have data for the following channels:// 16:21:11 s/#aria-apg (no topic data buffered)// 16:21:17 s/#css (no topic data buffered)// 16:21:27 s/#tt (no topic data buffered)// 16:21:34 s/#webdriver (no topic data buffered)// 16:21:41 rrsagent, make minutes 16:21:41 I have made the request to generate https://www.w3.org/2022/09/29-tt-minutes.html nigel 16:23:49 s|Topic: Do we want to allow inline styles? w3c/dapt#60|| 16:23:51 https://github.com/w3c/dapt/issues/60 : Do we want to allow inline styles? 16:23:53 rrsagent, make minutes 16:23:53 I have made the request to generate https://www.w3.org/2022/09/29-tt-minutes.html nigel 17:37:16 Zakim has left #tt 21:11:44 RRSAgent has joined #tt 21:11:44 logging to https://www.w3.org/2022/09/29-tt-irc 21:12:37 scribeOptions: -final 21:12:40 rrsagent, make minutes 21:12:40 I have made the request to generate https://www.w3.org/2022/09/29-tt-minutes.html nigel 21:13:09 s/can;t/can't 21:13:10 rrsagent, make minutes 21:13:10 I have made the request to generate https://www.w3.org/2022/09/29-tt-minutes.html nigel 21:29:53 rrsagent, excuse us 21:30:02 rrsagent, make logs public 21:30:06 rrsagent, excuse us 21:30:06 I see no action items