14:57:46 RRSAgent has joined #tt 14:57:50 logging to https://www.w3.org/2026/05/07-tt-irc 14:57:50 RRSAgent, make logs Public 14:57:51 Meeting: Timed Text Working Group Teleconference 14:58:01 Agenda: https://github.com/w3c/ttwg/issues/333 14:58:08 scribe: nigel 14:58:33 Previous meeting: https://www.w3.org/2026/04/23-tt-minutes.html 14:58:40 rrsagent, make minutes 14:58:41 I have made the request to generate https://www.w3.org/2026/05/07-tt-minutes.html nigel 14:59:48 Present: Nigel 15:00:19 Regrets: none 15:02:48 Present+ Chris_Needham, Pierre, Andreas 15:03:06 cpn has joined #tt 15:03:34 Topic: This meeting 15:03:42 scribe+ cpn 15:03:44 atai1 has joined #tt 15:03:58 Present+ Gary 15:04:03 Chair: Nigel, Gary 15:05:50 Nigel: (reviews the agenda). Anything else to add, or make sure we cover? 15:06:08 Andreas: Start discussion about TPAC meeting this year 15:06:18 present+ Atsushi 15:06:30 Present+ Atsushi 15:07:27 Topic: DAPT 15:08:23 Subtopic: Profile identifier and TTML registry 23c/dapt#248 15:08:31 github: https://github.com/w3c/dapt/issues/248 15:08:44 s/23c/w3c/ 15:09:16 Nigel: In preparing a PR for the TTML profile registry for DAPT, I noticed we have two profile designators, for the content profile and the processor profile 15:10:01 ... I don't recall why, though. And I notice we don't do this in TTML or IMSC, where we have a single profile designator that can be used for either 15:10:27 ... Does anyone have any views? If we want to change to be a single profile designator, it would be a substantive change, requiring a new CRD 15:10:59 ... But from the point of view of the profile registry, we'd have processor profiles with a different value than would appear in the DAPT documents. It's formally correct, but weird 15:12:19 .... The media type and profile registry contains profile identifiers as short codes, then a URN as designator and a specification 15:12:41 +1 15:12:46 ... For DAPT we'd have a processor profile identifier and content profile identifier that are kind of for the same thing, but kind of not. Does that help us in general? 15:12:47 ack at 15:13:24 Andreas: How do we expect people to use the designators? 15:13:59 Nigel: In the TTML profile registry and the codecs parameter, it's less clear what they should do. They could put in a processor profile 15:14:36 ... But they could specify a codecs value set to the content profile, even though the intent of that is to specify the kind of processor that can process the document, in which case you should use the processor profile 15:15:12 Andreas: Formally it's correct to handle DAPT in the same way 15:15:30 ... No strong view, but it would be easier to follow a certain pattern 15:15:51 Nigel: It can be done either way. So you suggest easier to have a single designator that can be used as either? 15:16:04 Andreas: Yes, just follow what we did before and have one designator 15:16:23 ... But i wouldn't oppose having two, if there are good arguments for that 15:16:46 Nigel: PRs 103 and 104 relate to this 15:17:35 ... 103 moreso than 104 15:17:40 ... I need to look more into the history of how we got here, but that's useful input, Andreas 15:17:43 ... Any other views? 15:17:48 (nothing) 15:18:04 nigel has joined #tt 15:18:04 gkatsev has joined #tt 15:18:04 mattp has joined #tt 15:18:04 slightlyoff has joined #tt 15:18:31 rrsagent, draft minutes 15:18:33 I have made the request to generate https://www.w3.org/2026/05/07-tt-minutes.html cpn 15:18:43 rrsagent, make log public 15:19:38 SUMMARY: @nigelmegitt to look again at #104, input from @cconcolato welcome, could be the best option is to use a single designator 15:20:01 Topic: IMSC 1.3 15:21:52 Nigel: The poll ends in 8 hours. Please vote if you haven't already 15:23:03 Topic: TTML Media Type Definition and Profile Registry 15:23:33 Nigel: There are 6 open issues and 5 PRs to address them. Please review those. 15:23:42 -> https://github.com/w3c/tt-profile-registry/pulls Pull Requests 15:24:40 Nigel: There was a question about an IRT document that I think is now owned by ARD. We should update the contact information, any update Andreas? 15:24:49 Andreas: What's the timeline for doing it? 15:25:15 Nigel: It's only a note, so can be whenever 15:25:41 ... I might create a separate issue for the contact info so we can merge the URL change 15:26:55 ... (Reviews the PRs) 15:28:02 Topic: WebVTT 15:28:59 Gary: There's a call for consensus which passed. Next steps? Atsushi has a couple of PRs, but is anything else needed? 15:29:38 Atsushi: I updated a PR with the boilerplate. Once that's merged we can run streamlined publication of the CRD 15:29:44 -> https://github.com/speced/bikeshed-boilerplate/pull/197 Bikeshed WebVTT boilerplate change PR 15:29:58 q+ 15:30:12 Gary: Once the bikeshed PR goes through, we can update the WebVTT PR to use that, which will unblock everything? 15:30:48 Atsushi: Yes, or we can merge the WebVTT one first 15:31:59 Nigel: The text that appears in CR for WebVTT, including the exit criteria, which is different to what we've had before. I think it's fine. It has more specific CR exit criteria in the charter 15:32:44 ... Is anything more specific for what that means for WebVTT? I welcome views on whether it should say more about what it means in the context of WebVTT 15:33:02 Gary: It's generic text for the WG 15:33:38 Atsushi: We could remove this from the boilerplace and put the exit criteria in the spec itself 15:34:09 ... I believe there's no strict requirement to say anything specific about the exit criteria in the boilerplate 15:34:22 Gary: Pointing to the charter sounds reasonable, rather than duplicating the text 15:35:20 Nigel: It's simpler to do that, which is good. Does any other CR do this? Will it cause any friction for other groups? 15:35:58 ... Such as horizontal review groups, or AC reviewers, I mean 15:37:06 Atsushi: The AC reviews the charter itself, so following the charter should be fine. The standard checklist is quite welcome for browser specs 15:37:37 Nigel: We forgot to put exit criteria in IMSC, so we put them in the implementation report, and there weren't any issues 15:37:53 Atsushi: The implementation report will be reviewed when we go to AC review 15:38:40 Gary: To summarise, we need to review the bikeshed boilerplate PR. Once merged, that'll unblock the WebVTT spec changes 15:38:56 ... Any other WebVTT topics to discuss? 15:39:09 (nothing) 15:39:44 Gary: One thing to mention, when James was summarising the attributes block discussion last time, he realised there are some edge cases we didn't address. 15:40:11 ... For example, custom attribute names, and we decided to require a hyphen in them, but we didn't address whether we want to disallow names that start with a hyphen. 15:40:43 ... There's a couple more, not major issues. But if anyone has time to review, or if you have thoughts now? 15:41:15 Nigel: It's a common pattern to prefix with a hypen, e.g., CSS property names, so it seems there's precedent for it 15:41:26 ... Any lessons from that experience? 15:42:13 Gary: I don't see downsides. The only reason not to allow it is if we wanted a get attributes method to camel-case the attribute name 15:42:31 ... But I don't think that's a strong case 15:42:57 Nigel: The expectation should be that the attribute keys should be portable into an HTML attribute 15:43:35 ... What should the behaviour be if the WebVTT attribute has a syntax you can't use in an HTML attribute? 15:44:02 Gary: Use the JavaScript API. We've discussed a getAttributes() API 15:45:07 Nigel: Now I'm in two minds whether it's a good or a bad thing. 15:45:44 ... There must be constraints on the JavaScript properties to avoid name conflicts 15:46:29 Gary: We could return a map object instead of a plain JS object. Good to look at how CSS handles properties starting with a hyphen 15:46:53 ... But I'm inclined to allow such properties at the moment 15:47:22 ... Or be more strict initially, and relax later 15:47:46 Nigel: In the absence of other guidance, it seems that's the WebVTT way 15:47:50 Gary: Sounds good. 15:48:16 s/other guidance/specific use cases 15:48:28 Gary: To summarise, look at how CSS handles camel casing of properties and whether it makes sense to use the same mechanism. Otherwise, start stricter and relax later 15:48:54 Topic: Impact of AI technologies on Timed Text Working Group's mission 15:49:25 -> https://github.com/w3c/webai-roadmap/issues/37 Team request for input 15:49:59 Atsushi: W3C is gathering information on the impact of AI on WGs. Any comment, please add to the issue 15:51:07 Nigel: I'm a bit puzzled. (Reads the group's mission in the charter.) 15:51:40 ... We're defining interchange formats, and we don't say anything about how they're produced or consumed. Nobody has asked for AI specific changes so far 15:52:04 ... So from that point of view, there's no obvious change needed to our mission 15:52:13 q+ 15:52:14 ... Interested to hear other views 15:52:25 ack n 15:52:33 ack at 15:53:19 Andreas: No particular proposal, but there have been discussion about metadata that should be carried with timed text, verify how timed text can be used in this context. 15:54:04 ... One thing that's related, use timed text formats to transport timed metadata instead of timed text 15:54:18 ... Not sure if we want to cover that use case, but people do use the formats in that way 15:54:38 q+ 15:55:15 Nigel: If something additional is needed related to AI, people would be asking for it. We haven't heard so far 15:55:40 Andreas: There may be requirements from people not in the group, though 15:56:42 ... There was the question of interoperable metadata, e.g., the quality of generated text based on the AI engine. How TTML is used in this context could be improved, but not necesasrily something the group needs to work on. Would be good to verify that 15:57:39 Nigel: A question I'd have for Dom, who raised the issue, is how tightly scoped to the mission in the charter is the question? Or is he more interested in other things that may be relevant? 15:58:43 Atsushi: I believe the intent is to gather any related impact, so AI related metadata could be an impact. If it's not in the scope of the charter, we could list them as potential impacts 16:01:41 Chris: It may be broader, relating to production and consumption of timed text in general 16:02:30 Gary: One thing that could be helpful, is having mixed timed text and metadata content in the same file, which is doable in TTML now, but not in WebVTT 16:02:55 ...We're adding attributes for file-level metadata, which could be used to note the content is AI generated 16:03:07 ... But it doesn't change the group's mission 16:03:12 Nigel: I agree 16:03:43 Topic: Meeting close 16:03:52 Nigel: Thank you everyone, we're at time. 16:04:35 .. Next meeting is in 2 weeks, 2026-05-21, agenda is w3c/ttwg#339 16:04:39 .. [adjourns meeting] 16:04:46 rrsagent, make minutes 16:04:48 I have made the request to generate https://www.w3.org/2026/05/07-tt-minutes.html nigel 16:20:54 s/WebVTT boilerplate/TTWG boilerplate 16:22:29 rrsagent, make minutes 16:22:30 I have made the request to generate https://www.w3.org/2026/05/07-tt-minutes.html nigel 16:23:22 rrsagent, make minutes 16:23:23 I have made the request to generate https://www.w3.org/2026/05/07-tt-minutes.html nigel 16:24:00 scribeOptions: -final -noEmbedDiagnostics 16:24:07 zakim, end meeting 16:24:07 As of this point the attendees have been Nigel, Chris_Needham, Pierre, Andreas, Gary, Atsushi 16:24:09 RRSAgent, please draft minutes v2 16:24:10 I have made the request to generate https://www.w3.org/2026/05/07-tt-minutes.html Zakim 16:24:16 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:24:17 Zakim has left #tt 16:24:21 rrsagent, excuse us 16:24:21 I see no action items