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