Meeting minutes
This meeting
Nigel: Agenda for today is:
… DAPT - Implementation activity
… How we write about DAPT and IMSC compat
… and IMSC - we have some items flagged for the agenda
… AOB?
no AOB
DAPT
Interoperability session 2026-01-26
Nigel: Cyril and I, and an observer from VRT in Belgium,
… had an interoperability session on Monday.
… It went pretty well.
… Netflix's open source converter generated a set of DAPT files.
… BBC's (not yet open source) ttml validator validated them.
… It found one issue, which Cyril was able to address.
… But otherwise it was really positive.
… And the action to come out of it is to update the implementation report,
… which is a bit complex because we're leaning on both the CR exit criteria and
… the Charter success criteria to make the case for progressing.
… There are one or two features that still have one implementation, which we're thinking about.
… Any questions?
Andreas: The BBC validator is just for DAPT or generic TTML validator?
Nigel: At the moment it validates that input documents meet the BBC Subtitles Guidelines for EBU-TT-D,
… or that they are valid DAPT. It's written in a way that can be extended for other profiles.
DAPT and IMSC compatibility (editorial)
Nigel: We have two open pull requests, one for DAPT, the other for IMSC 1.3.
Nigel: There's a lot of commonality between these PRs
… From the review of the IMSC one, the best way to proceed isn't completely obvious
… Pierre mentioned not being happy with duplicating text between the specs
… There's been discussion on DAPT PR #333
Pierre: The reason for having compatibility sections in either of them, is if there's overlap in the use cases or workflows for DAPT and IMSC
… The only practical overlap I've heard is someone wishing to create DAPT documents that might be played back on an IMSC renderer, for a quick check I guess
… IMSC doesn't understand DAPT metadata
… Otherwise, documents in DAPT workflows are entirely different from documents in IMSC workflows
Nigel: The key point is how one is derived from the other
Pierre: Documenting how to convert one to the other might be good, but that's not about compatibility
Nigel: There's text in DAPT about directing the text presentation of IMSC documents. So a transformation where you take the character data and use that to change the output when you create the IMSC document, to indicate changes of speaker, is appropriate for the destination
… Or filtering on subsets of the text content, for dialog or captions. Selecting based on the language or text language source to generate subtitles
… Places where it makes sense to start with DAPT and generate IMSC
… Starting from a DAPT workflow, where is the right place to start that. Might vary between different people's workflows.
… An option might be to capture, position-wise, in the DAPT stage, in a way that's conformant to IMSC, and you can flag that it's conformant to both DAPT and IMSC
… That could be useful before leaving the DAPT stage. So it's more than using IMSC in a preview environment (which is also a use case)
Pierre: Sounds like how turn DAPT docs into IMSC is already in the PR. That's different than, when you transform to IMSC it's no longer a DAPT document. So are there scenarios in DAPT workflows where you want to create a document that's both a DAPT and an IMSC document?
… Those are both DAPT concerns, not IMSC concerns
Nigel: What if the IMSC documents that you distribute include DAPT metadata?
… If you want the player to do some thing with that metadata, having it signalled as both a DAPT and IMSC document might be useful for that player
… For example, the names of speakers where you could show non-caption/subtitle metadata
Pierre: An IMSC player would ignore the metadata, so what you're describing wouldn't be an IMSC player
Nigel: During normal playback it could show the IMSC, but inclusion of other data doesn't make it not an IMSC player. Maybe we don't need to go down this rabbit-hole...
Pierre: Don't think this belongs in IMSC, could be some other spec.
… IMSC from the beginning was attempting to reduce fragmentation in distribution of subtitles and captions using TTML
… Those sections on interop with other specs, are there to show that documents will play with high fidelity in an IMSC player
… Example, EBU-TT-D, you can distribute the same documents to IMSC players
… The same for SMPTE-TT documents, will play fine in an IMSC player
Nigel: So, what to do? I sense you're not uncomforable with the DAPT PR, but you are uncomfortable with the IMSC PR
Pierre: Yes
… I don't think, from an IMSC player or author perspective that it's relevant information. The more text there is, the more effort it takes to maintain
Nigel: Makes sense. I think I'm getting to just merge the DAPT PR and not the IMSC PR. Anything useful we can say in IMSC on DAPT?
… It felt useful to me to point readers to DAPT, to at least say that you could make IMSC documents from a DAPT workflow, and refer to DAPT for details
Pierre: Could find a logical place to do that, e.g., in the Introduction on where IMSC documents come from
… A question that has come up in previous years is where IMSC documents come from, so that could be a place
Nigel: I was thinking of Appendix I, on compatibliity with other formats
Pierre: I'd prefer having text on where IMSC documents come from, more so than having example. The question comes up multiple times
… MDN doesn't say where IMSC documents come from
Nigel: There are different views, e.g, for some people they come from CEA-608 documents
… It's timely now as people are thinking of automated subtitle workflows
… BBC converts teletext to EBU-TT-D...
Nigel: Any other views on this?
Andreas: What you've both said makes sense
Nigel: Two actions to take. One is to close the IMSC PR and the associated issue. Then open a new issue in IMSC to add an editorial section to talk about the authoring workflows for IMSC, e.g., in the Introduction
Nigel: I thought this would be a useful addition to IMSC, but I'm deferring to the editor
Nigel: I think all review comments in the DAPT PR have been done, so can merge it
Pierre: Yes
… There's no other discussion in the IMSC PR, so can close it
IMSC 1.3
Fixed github link metadata w3c/imsc#631
github: w3c/
Pierre: That's simple, question is who should merge it
SUMMARY: @palemieux to merge
Add Examples section to Introduction and add some renderings w3c/imsc#632
github: w3c/
Nigel: It's a draft PR for now, to add examples to the Introduction, and add some renderings
… I want to check in before I do more on this
… It adds some orientation information for people unfamiliar with the spec. But want to pause to discuss
Pierre: On the rendered examples, it's not a bad idea. But I'd rather we use actual examples. Those examples demonstrate the syntax but they're artificial
… Would it be possible to use a real example, and actual document or fragment?
Nigel: I already have something like that in the BBC Subtitle Guidelines, so that's easy to do, but it takes up a lot of space
https://
Pierre: Have a frame from a BBC show with the EBU-TT-D fragment, showing how it's used in practice?
Nigel: Would that be useful?
Pierre: I'm trying to think of something that's not been done elsewhere. MDN has examples. The IMSC test suite has exhaustive examples
… What's missing is how it shows up in practice
Nigel: The BBC Subtitle Guidelines is a real world example
… [Shows the BBC example]
Pierre: I think that's awesome. I'd just include this. The region stuff is helpful
… It could go in an Annex if it's too long
… Add an acknowledgement too
Nigel: OK, yes
Chris: Move it to an Annex?
Nigel: For people reading from the top, and want orientation, I think it should go in the Introduction. Much easier than reading through the spec detail
Pierre: I'm fine with putting it in the Introduction.
Nigel: And leave the rendering examples in place in the PR?
Pierre: That's fine, no strong opinion. Could link to them if in they're in the test suite
SUMMARY: @nigelmegitt to add example, remove pointers in 2.1 to other examples, leave renders in place.
AOB
Nigel: Anything else to cover today?
… Welcome back Pierre as IE!
Meeting close
Thanks everyone, next meeting is in 2 weeks on 2026-02-12, w3c/ttwg#327
(adjourned)