- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 29 Jan 2026 17:12:34 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <1A14FD39-1507-4079-BCF6-4893FA5404C6@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2026/01/29-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
29 January 2026
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2026/01/15-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/326
[4] https://www.w3.org/2026/01/29-tt-irc
Attendees
Present
Andreas, Atsushi, Chris, cpn, Gary, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel, cpn
Contents
1. [5]This meeting
2. [6]DAPT
1. [7]Interoperability session 2026-01-26
3. [8]DAPT and IMSC compatibility (editorial)
4. [9]IMSC 1.3
1. [10]Fixed github link metadata w3c/imsc#631
2. [11]Add Examples section to Introduction and add some
renderings w3c/imsc#632
5. [12]AOB
6. [13]Meeting close
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.
[14]w3c/dapt#332
[14] https://github.com/w3c/dapt/issues/332
[15]w3c/imsc#622
[15] https://github.com/w3c/imsc/issues/622
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
[16]w3c/dapt#333 pull request
[16] https://github.com/w3c/dapt/pull/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 [17]w3c/imsc#631
[17] https://github.com/w3c/imsc/issues/631
github: [18]w3c/imsc#631
[18] https://github.com/w3c/imsc/pull/631
Pierre: That's simple, question is who should merge it
SUMMARY: @palemieux to merge
Add Examples section to Introduction and add some renderings
[19]w3c/imsc#632
[19] https://github.com/w3c/imsc/issues/632
github: [20]w3c/imsc#632
[20] https://github.com/w3c/imsc/pull/632
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
[21]https://www.bbc.co.uk/accessibility/forproducts/guides/
subtitles/#Example-EBU-TT-D-document
[21] https://www.bbc.co.uk/accessibility/forproducts/guides/subtitles/#Example-EBU-TT-D-document
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,
[22]w3c/ttwg#327
[22] https://github.com/w3c/ttwg/issues/327
(adjourned)
Minutes manually created (not a transcript), formatted by
[23]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).
[23] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 29 January 2026 17:12:46 UTC