15:00:48 RRSAgent has joined #tt 15:00:53 logging to https://www.w3.org/2025/09/11-tt-irc 15:00:53 RRSAgent, make logs Public 15:01:01 Meeting: Timed Text Working Group Teleconference 15:01:33 Present: Atsushi, Nigel, Pierre 15:01:36 Chair: Nigel 15:01:44 Agenda: https://github.com/w3c/ttwg/issues/315 15:01:51 Previous meeting: https://www.w3.org/2025/08/28-tt-minutes.html 15:01:58 Present+ Gary 15:02:04 Chair: Nigel, Gary 15:02:25 Present+ Andreas 15:03:22 Topic: This meeting 15:03:36 scribe: nigel 15:03:41 Regrets: Chris_Needham 15:04:03 Nigel: Today we have a busy agenda. 15:04:24 .. DAPT bits and pieces, IMSC 1.3 - the ARIB incoming liaison and consequences, 15:04:47 .. a couple of WebVTT issues and TPAC 2025 planning 15:04:57 .. Any other business or points to make sure we cover? 15:05:16 .. I have something small about our group wiki page. 15:05:19 atai has joined #tt 15:05:22 Present+ Cyril 15:05:39 no other business 15:05:56 Topic: DAPT 15:06:18 Subtopic: CR Snapshot publication 15:06:43 Nigel: I don't think we've had any HR responses yet, as tracked in w3c/dapt#307 15:06:50 Atsushi: I don't see any comments yet 15:07:16 .. Some of the HR groups had August vacations. 15:07:54 Subtopic: Issues and pull requests for discussion 15:08:02 Nigel: Some issues were raised since the last call. 15:08:12 .. I fixed the typo/editorial type issues directly. 15:09:06 Subtopic: Use xref to resolve TTML2 and w3c-process links w3c/dapt#313 15:09:21 Nigel: This addresses that some links to TTML2 went to the current Rec 15:09:29 .. and others to the most recent CR snapshot. 15:09:34 pal has joined #tt 15:09:37 .. I requested review. 15:10:00 .. The pull request changes all the hrefs to TTML2 to point to the latest CR snapshot. 15:10:22 .. It needs a review approval before it can be merged. 15:10:25 Atsushi: I have not commented yet. 15:10:53 .. My concern is that for TTML2 we make /TR/ttml2 point to the latest Rec even though 15:11:00 .. we have some CR publications. 15:11:13 .. We should be consistent but I haven't had time to check. 15:11:21 .. Let me have some time to look. 15:12:16 SUMMARY: @himorin to check this 15:12:30 github: https://github.com/w3c/dapt/pull/313 15:13:16 Subtopic: Use of src on embedded content entities appears to conflict with TTML2 w3c/dapt#312 15:13:24 github: https://github.com/w3c/dapt/issues/312 15:14:58 Nigel: Raising this here for visibility. 15:15:11 .. It needs a fix I think, preferably before CRS. 15:15:19 .. It's a spec bug by the looks of it. 15:15:32 .. I don't think it's too hard to fix; my plan is to raise a PR. 15:15:54 .. If when I raise it we can review it reasonably speedily and get it merged that would help 15:16:07 .. us avoid needing another CRS after the one we're working towards now. 15:16:18 SUMMARY: @nigelmegitt to open a PR to fix. 15:16:51 Topic: IMSC 1.3 15:17:08 Subtopic: Incoming liaison from ARIB 15:17:18 Nigel: We received an incoming liaison from ARIB 15:17:30 .. Pierre I think you've already taken some action based on this. 15:18:02 Pierre: Yes, let's start with w3c/imsc#616. 15:18:28 Subtopic: ARIB liaison 2025-09-05: Table 1. Base Character Set w3c/imsc#616 15:18:34 github: https://github.com/w3c/imsc/issues/616 15:18:49 Pierre: My understanding of the issue is that IMSC recommends that authors use certain 15:18:59 .. characters depending on language. 15:19:12 .. There's a base set that can always be used, and all implementations should support it 15:19:16 .. regardless of language. 15:19:29 .. That base set has been in IMSC since time immemorial, and if I'm not mistaken it was derived 15:19:35 .. from Blu-ray and home video titles. 15:19:44 .. My understanding of the ARIB comment is that for their application the base set should not 15:20:00 .. contain some characters, because they don't consider them as being universally needed. 15:20:14 Cyril: Those that they suggest are not universal - I assume they're not Japanese? 15:20:35 Pierre: They're things like horizontal bar, trademark sign, vulgar fraction 2/5, punctuation, 15:20:43 .. graphic signs, service mark sign. 15:20:52 .. I think some of those are not uncommon. 15:21:08 .. My take on this is that's exactly why support for the base character set is a SHOULD not a SHALL 15:21:22 .. specifically for that reason, that those characters are not necessarily completely universally 15:21:24 .. applicable. 15:21:38 .. My recommendation is that we do nothing and point out that it's a SHOULD and that in general 15:21:50 .. people are encouraged to support as many Unicode characters as possible. 15:22:07 .. Internationalisation was surprised we even had [sub]sets. 15:22:34 Nigel: That makes sense to me. 15:22:44 Pierre: I've labelled it as Won't Fix and provided a rationale. 15:22:53 .. We should probably include that in our disposition in a liaison back to ARIB. 15:23:03 Nigel: Any other views or comments? 15:23:15 Cyril: You're suggesting Won't Fix. What would be the alternative, the next best solution? 15:23:35 Pierre: The real issue is that this table, the base set, has been in IMSC forever. 15:23:50 .. Trying to edit it partially would be a very significant undertaking and maybe pointless at the end. 15:24:03 Cyril: I was thinking of other options. We could completely remove the base set. 15:24:11 .. It's a SHOULD, if nobody implements it, what's the point? 15:24:23 Pierre: It's been there for people who maybe don't know. 15:24:33 .. Maybe things are different from in 2008 or 2012. 15:24:47 .. If somebody creates a renderer and needs to know which characters amongst all of Unicode 15:24:47 q+ for agree with SHOULD, if we left as wontfix, we may need to weaken it somehow... 15:24:59 .. they need to support, the base set plus language specific sets are a good place to start. 15:25:14 .. If you're a specialist who knows better for local needs, then you can do what works for you. 15:25:33 .. For a renderer on an embedded device it makes sense to use those tables to subset the 15:25:43 .. characters supported, and those tables are incredibly useful. 15:26:01 q+ 15:26:02 Gary: There's already a note that it's not intended to limit processors from deciding what to render. 15:26:21 Pierre: I think it was a reasonable compromise between "all of Unicode" and "what's in 608". 15:26:23 q? 15:26:28 ack ats 15:26:28 atsushi, you wanted to discuss agree with SHOULD, if we left as wontfix, we may need to weaken it somehow... 15:26:54 Atsushi: Reading the spec strictly, instances should be using the character sets in Appendix B too, 15:27:15 .. a SHOULD, and there's a note in B saying it's not intended to limit the set of possible characters 15:27:35 .. the processor understands. Reading it strictly, it's a processor minimum (that SHOULD be supported) 15:27:44 .. We first added to the ja table in 1.3 draft. 15:27:52 .. There is inconsistency between ARIB 1 and what we have here. 15:28:06 .. There may be inconsistency between the IMSC 1.3 definition and the ARIB one. 15:28:12 s/ARIB 1/ARIB one 15:28:32 .. I propose to add a note about the ja set that some characters could be omitted from the base 15:29:15 .. set to weaken the minimum requirement for the processor for ja specifically. 15:29:42 .. If not, there's an inconsistency at the SHOULD level compared to ARIB that could cause some 15:29:45 .. issues in the future. 15:29:51 q? 15:29:55 ack atai 15:30:11 Andreas: I don't have a strong view. Question: is there any indication that those base characters 15:30:25 .. are actually used? Do we have feedback about which characters are used? 15:30:38 .. Otherwise we could remove it because it is nearly impossible for us to review if the base set 15:30:40 .. is the correct one. 15:30:41 q? 15:31:09 Pierre: I will quadruple check, but these characters came from the original member submission. 15:31:12 .. [checks] 15:31:40 .. Yes, that came from the initial member submission - it definitely had a character set. 15:31:47 .. That was the result of actual study of home video material. 15:31:55 .. And the intersection with 608 and 708. 15:32:03 .. There's a basis for those tables, they're not random. 15:32:09 .. Since then they've been updated. 15:32:30 .. To the question of usage, unfortunately like all voluntary standards with no licensing we have 15:32:44 .. no idea who uses IMSC. If the criteria depend on knowing about usage we would have no spec! 15:33:02 .. I'm not excited to remove text that is only a recommendation. 15:33:14 .. This would be a very different conversation if we were talking about convergence with ARIB 15:33:28 .. and ultimately ARIB referencing IMSC and not ARIB-TT then it would be different. 15:33:39 .. It would be reasonable at least to have a note. We might not want to create a ja set that 15:33:55 .. conflicts with past ARIB-TT practice. As far as I can tell ARIB-TT will continue being a separate 15:34:00 .. specification managed separately. 15:34:12 .. So I do not want to impose additional constraints on IMSC at this time. 15:34:35 Nigel: For a local usage it is reasonable to impose additional constraints on IMSC if they make 15:35:03 .. sense. So an adopter could say "IMSC but with SHALL support for some specific set of characters" 15:35:18 .. that they define, and that wouldn't be non-conformant with IMSC at all as it stands. 15:35:27 .. I think that's an argument in favour of Won't Fix. 15:35:48 Pierre: Again, it's not clear from the liaison but if ARIB is interested in discussing convergence 15:35:54 .. this might be a different discussion. 15:36:16 .. Maybe we ought to ask about that when we get back to ARIB. 15:36:44 Nigel: Does anyone think Won't Fix is not what we should be doing here? 15:36:58 .. Hearing nothing, that's the summary then. 15:37:35 SUMMARY: TTWG discussed 2025-09-11 and no proposal other than Won't Fix was made. A possibility was raised to add a ja-specific note. 15:38:29 Subtopic: The reference to the Unicode Standard should be undated w3c/imsc#617 15:38:36 github: https://github.com/w3c/imsc/issues/617 15:38:58 Nigel: This is related to w3c/imsc#615. 15:39:30 Pierre: There are many layers to this. At a high level, Unicode is a living standard that 15:39:42 .. is evolving regularly, with new languages being added, corrections being made etc. 15:39:56 .. I don't think it ever makes sense to take a single dated snapshot and be done. 15:40:12 .. The way to convey that is to reference the undated, i.e. latest, version of Unicode. 15:40:25 .. That's my general recommendation with Unicode. 15:40:43 .. Today in the current draft it is the 2020 version. 15:40:51 .. I think we should remove that and always point to latest. 15:41:25 .. Added to that, ISO has withdrawn older versions of some standards, 15:41:33 .. so pointers to old versions will stop working. 15:41:43 .. I don't see any reason not to point to the undated latest version. 15:42:06 Nigel: That makes sense. 15:42:25 .. The general counter-argument is that it means that point in time implementations 15:42:44 .. that are valid or conformant when created can suddenly stop being conformant later, 15:42:59 .. even though they point to a specific dated version of say IMSC in this case. 15:43:30 .. For a Consumer Electronics device where some claim of conformance might be made, 15:43:38 .. it leaves the manufacturer in an open-ended situation. 15:43:57 .. The reason for not worrying about that too hard here is that Unicode doesn't tend to 15:44:25 .. do unpleasant things like reassigning code points. It's more an additive process. 15:44:38 Cyril: I was about to make a similar comment. It depends on the standard you're referring to. 15:45:20 .. If the standard is adding features, not to mention making non-backward compatible changes, you 15:45:24 .. don't want an undated version. 15:45:33 .. Is Unicode "adding features" whatever that means? 15:45:57 Pierre: Typically the most common one is adding new languages and characters for those languages. 15:46:09 .. Unicode is not only code points but also a large library of localisation information. 15:46:21 .. They have the CLDR language recommendations that typically get updated. 15:46:33 .. I'm not aware of them ever removing characters or changing the way code points work. 15:46:57 Atsushi: Maybe there are two possible links - the ISO version or the Unicode one. 15:47:19 .. The ISO one is updated every 2-3 years I understand. 15:47:42 .. Then if we refer to the Unicode-consortium published one, it has an additional set 15:47:58 .. of information called UCS features, such as things implemented in CLDR or other libraries. 15:48:05 q+ 15:48:24 .. For glyphs and their code points, once it is added to a Unicode code point it is never deleted. 15:48:43 .. Sometimes a foreign feature, like a double exclamation mark, has been marked as an emoji 15:49:01 .. and changed from a black and white glyph to a colourful one - Unicode can make that change. 15:49:18 .. I totally agree that we are better to refer to the non-dated version but I am not sure which 15:49:22 .. one to use, ISO or Unicode. 15:49:25 q- 15:50:45 Nigel: Do you have to pay for the ISO standard? 15:50:56 Pierre: Not that one. I have a pull request that points to the undated ISO one. 15:51:06 .. It's an update to what was there before. 15:51:20 Nigel: On the basis that that's the smallest change it's probably the right thing to do. 15:51:27 Pierre: Also that's what ARIB references. 15:52:10 Atsushi: The WHATWG references the Unicode one, just for information. 15:52:26 -> https://infra.spec.whatwg.org/#biblio-unicode WHATWG Infra spec Unicode reference 15:53:01 SUMMARY: Group to review w3c/imsc#618 pull request to resolve this. 15:54:46 Topic: Can ::cue(selector) match a list of webvtt node objects? w3c/webvtt#533 15:54:55 github: https://github.com/w3c/webvtt/issues/533 15:55:05 Gary: We discussed this in the WebVTT Interop meeting yesterday 15:55:38 SUMMARY: @gkatsev to summarise the WebVTT Interop meeting conclusion about this 15:56:07 Gary: Example 22 needs updating and the styling under the cue text parsing rules needs fixing for clarity. 15:56:32 Topic: TPAC 2025 planning 15:56:44 Nigel: I created a wiki page for our f2f at TPAC 15:56:58 -> https://www.w3.org/wiki/TimedText/tpac2025 TTWG TPAC2025 wiki page 15:57:15 Nigel: It needs populating, there are some draft topics in there. 15:57:28 .. We also need to think about timing, if some times of day are better for some topics than others. 15:57:46 .. There is a link to the people in this WG who have registered for TPAC. 15:58:39 .. In passing I noticed that our TTWG wiki pages were quite out of date 15:58:54 .. so I spent some time fixing them and adding in historic face to face meetings that were absent. 15:59:14 -> https://www.w3.org/wiki/TimedText TTWG wiki home page 15:59:47 Nigel: We probably have too many home pages! 15:59:50 .. If you are going to TPAC please add yourself. 16:00:02 Gary: Would be useful to have a session for remote attendees and their timezones so that 16:00:11 .. we can try to schedule relevant topics appropriately. 16:00:15 Nigel: Great idea. 16:00:33 .. I'll try to do that unless someone else gets there first. 16:01:45 Topic: Meeting close 16:01:56 Nigel: We're at time, so let's adjourn. 16:02:05 .. Next meeting is 2025-09-25 16:02:26 -> https://github.com/w3c/ttwg/issues/316 Meeting issue and agenda for 2025-09-25 call 16:02:37 Nigel: Thank you everyone. [adjourns meeting] 16:02:41 rrsagent, make minutes 16:02:42 I have made the request to generate https://www.w3.org/2025/09/11-tt-minutes.html nigel 16:15:51 scribeOptions: -final -noEmbedDiagnostics 16:15:54 zakim, end meeting 16:15:54 As of this point the attendees have been Atsushi, Nigel, Pierre, Gary, Andreas, Cyril 16:15:56 RRSAgent, please draft minutes v2 16:15:58 I have made the request to generate https://www.w3.org/2025/09/11-tt-minutes.html Zakim 16:16:04 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:16:04 Zakim has left #tt 16:16:15 rrsagent, excuse us 16:16:15 I see no action items