- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 21 May 2026 16:21:10 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <56B5F74C-0986-42D5-A506-5C6EED99E438@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2026/05/21-tt-minutes.html
We made 1 resolution:
RESOLUTION<https://www.w3.org/2026/05/21-tt-minutes.html#69a5>: Auto-publish the TTML Profile Registry as a Note on pull request merge, based on the usual TTWG Decision policy applying to pull requests
The review period for this resolution, as per our Decision Policy<https://www.w3.org/2025/06/timed-text-wg-charter.html#decisions>, ends on 2026-06-04, in 2 weeks’ time. If you have any queries, objections or other comments about this resolution, please respond by email to the group, using either the public or member-only email reflector.
Those minutes in plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
21 May 2026
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2026/05/07-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/339
[4] https://www.w3.org/2026/05/21-tt-irc
Attendees
Present
Andreas, Atsushi, Chris_Needham, Cyril, Dana, Gary,
Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel, cpn, cpn3
Contents
1. [5]This meeting
2. [6]IMSC 1.3
3. [7]TTML Media Type Definition and Profile Registry
4. [8]DAPT
1. [9]Profile identifier and TTML registry w3c/dapt#248
5. [10]WebVTT
1. [11]License
6. [12]TPAC Planning
7. [13]Impact of AI technologies on Timed Text Working Group's
mission
8. [14]Next meeting
9. [15]Meeting close
10. [16]Summary of resolutions
Meeting minutes
This meeting
Nigel: One DAPT issue, IMSC 1.3 final details and Rec
published, TTML Media Type and Profile Registry, WebVTT license
… Impact of AI technologies on our mission, and TPAC planning
… Anything else?
(Nothing)
IMSC 1.3
[17]Latest publication REC 2026-05-21
[17] https://www.w3.org/TR/ttml-imsc1.3/
Nigel: We published Rec today. Congratulations and thanks
everybody for your work on it
[18]News item
[18] https://www.w3.org/news/2026/imsc-text-profile-1-3-is-now-a-w3c-recommendation/
Pierre: Thanks everybody for helping push it along
… Could discuss IMSC Image Profile today?
[19]unversioned IMSC link
[19] https://www.w3.org/TR/ttml-imsc/
Nigel: This link takes you to IMSC 1.3, but that doesn't refer
you to 1.2 for the Image Profile. Propose adding to the
Abstract to point people there
Pierre: I prefer either to change nothing - as IMSC Image
Profile is a specialist tool, and our survey showed very few
people use it, and we don't really want people adopting it
going forward. So it's ok not to link to it
… Also, not a great idea to bake a link to 1.2 in the abstract
in case there needs to be a new version of Image Profile in
future
… May be better to acknowledge there are two profiles of IMSC,
and have two canonical links to track each of the profiles
Nigel: The canonical link we have is derived from the shortname
Pierre: I realise the second option is ambitious, so I actually
prefer to do nothing
Nigel: Any other views?
Andreas: Unless we hear complaints, do nothing
Cyril: IMSC versions are usually supersets of previous
versions, and the Image Profile in 1.3 so it's not a superset
Pierre: Each version of a profile is a superset of the profile
Cyril: Otherwise my suggestion would have been not to mention
the Image Profile, but make a blanket statement to refer to the
previous version
Pierre: We have that statement, just not in the Abstract
Nigel: Do nothing seems to have enough consensus for now
… Atsushi, there's some complexity with errata and release
tags. Anything else we need to do?
[20]Pull request to revert to ED from Rec
[20] https://github.com/w3c/imsc/pull/644
Atsushi: We need to get the github.io version to ED per request
from the Guide. Streamlined publication for IMSC 1.3 has Rec as
final state. I commented out the publication status from the
GitHub action
Nigel: So if we start working on a new version, we get a new
token
Atsushi: Yes
Nigel: So the action is to create the release tag based on
what's in the repo now. Pierre, do you want to do that?
Atsushi: You can create a tag from the current HEAD
Nigel: Yes, especially since there's no change to the Abstract
Pierre: Why did the CI fail?
Atsushi: It tried to update /TR
Pierre: I'll compare the HEAD of the main branch with the
actual Rec, check there's no differences, then create the tag
Nigel: Sounds good. Thank you
[21]TTML Profile Registry entry for IMSC 1.3
[21] https://github.com/w3c/tt-profile-registry/issues/87
[22]PR, needs an approve
[22] https://github.com/w3c/tt-profile-registry/pull/90
Nigel: There's a PR for this issue. It just needs approving,
now IMSC 1.3 is at Rec
Pierre: I'll approve that
Nigel: Thank you
Atsushi: The publication token is tied to the shortname, so if
you change that you need a new token
… If the WG wants to update the Abstract, it should update in
place of the Recommendation, so there's a checklist. There'd be
no ReSpec source for that
Nigel: For now, we won't change the Abstract
… Anything else to cover on IMSC 1.3?
(Nothing)
Nigel: Thanks again Pierre for all your effort
TTML Media Type Definition and Profile Registry
Nigel: I think we don't have auto-publication for this?
Atsushi: We can configure it for any publication
Nigel: That would be good
Atsushi: Once we've resolved to use streamlined publication for
the Registry. In the past we decided one by one, so just need a
resolution
PROPOSAL: Auto-publish the TTML Profile Registry as a Note on
pull request merge, based on the usual TTWG Decision policy
applying to pull requests
Chris: Sounds good to me
<atsushi> +1
<atai> +1
RESOLUTION: Auto-publish the TTML Profile Registry as a Note on
pull request merge, based on the usual TTWG Decision policy
applying to pull requests
Nigel: There are some PRs open. Please review
DAPT
Profile identifier and TTML registry [23]w3c/dapt#248
[23] https://github.com/w3c/dapt/issues/248
github: [24]w3c/dapt#248
[24] https://github.com/w3c/dapt/issues/248
Nigel: When I raised a PR to add the DAPT profile identifier to
the profile registry, I realised DAPT is different as it has
two profiles shown, which are one for the content profile, and
one for the processor profile
… I didn't find where this originated. The profile registry
should have the processor profile
… And the DAPT documents ttp:contentProfile attributes will
have the content profile
… That might be confusing for people. Maybe we change it so
there's one profile designator
… Processor profiles have mime type parameters, whereas content
profiles says what profile the content conforms to
Cyril: I looked at the DAPT spec, the only use we have for
Processor Profile, besides its formal definition, is in a Note
that says that normally you shouldn't use it, unless you have
particular processor requirements you need to express
… We have no tests exercising that
… It's a bit annoying to have to issue a new CR for this,
but...
Nigel: Formally, having different designators makes sense, but
then balance that against potential for confusion. I think
people will expect them to be the same
Cyril: There's a table in Annex F, explaining what features are
required, optional, and how they're treated in the processor
and content profiles
… If we remove the processor profile completely, how to deal
with that?
Nigel: Not suggesting removing the profile, just use the same
designator
… That's defined in 5.6 at the moment
… All we need to do is remove the word "content" and
"processor" from each, and everything else stays the same
Cyril: Not sure why we introduced the processor profile
concept, may be about audio that's supported by some tools
… But I remember the Note in 5.6.4 about not using the
processor profile attribute
… I need to think about this, but my inclination is to remove
mention of the processor profiles
Nigel: I want to make the smallest change possible, which is
changing the designator, so both profiles use the same
designator
Nigel: I can open a PR that makes this change for us to
consider and make a decision based on that?
Cyril: OK
Andreas: How can we define two different profiles with a single
designator?
Nigel: Both the processor profile and content profile each have
a profile designator, but we make them the same value, instead
of one being /content and one being /processor
… There are no content profiles in the profile registry now.
Even TTML2 defines content profiles and processor profiles,
with the same designators
Cyril: IMSC only talks about a profile designator
Andreas: You can still distinguish them by setting the type
attribute?
Nigel: Yes, exactly
SUMMARY: @nigelmegitt to open pull request making the content
and processor profile designators the same value
WebVTT
License
Nigel: Historically WebVTT had a different license to other
TTWG Recs. I think we decided to maintain that state
… But at some point it was changed?
Atsushi: I checked the record, and decision to use Software and
Document license for WebVTT in chartering in 2016
… From that point, WebVTT shall be published using Software and
Document license
… From 2019, it used the Document license, in the publication,
so I was confused
Gary: The Software and Document license is a little more open
than the Document license and
… that's what we used in the CG. It makes sense to keep it.
Nigel: I don't know why it was changed. I think we discussed
allowing TTWG to choose license on a spec by spec basis
[25]Charter section on Licensing
[25] https://www.w3.org/2025/06/timed-text-wg-charter.html#licensing
Gary: I assume it was a mistake when we made the snapshot
Nigel: So we can revert it to the Software and Document
license. That needs updating in the Bikeshed boilerplate PR?
Atsushi: Already done
Nigel: Anything else on WebVTT?
(Nothing)
TPAC Planning
Andreas: I'm interested to know if we have enough topics to
discuss at TPAC, and whether people are attending, to help
decide whether to travel
Nigel: I assume we would want to meet. Good to ask about
topics. We're approaching completion on DAPT, might be done by
then, there might be implementation things to discuss
… As Chair, I want to get TTML2 2nd Edition published. That's
another topic
… WebVTT topics?
Gary: Maybe, but I may not be there in person
Nigel: Any interop topics to discuss?
Dana: I'd like to discuss that at TPAC. I've been working on
the VTT interop investigation. I'm planning starting a monthly
meeting soon, to keep people posted on what's happening
Gary: TPAC2026 is the last week of October in Dublin
Impact of AI technologies on Timed Text Working Group's mission
Nigel: We started discussing this in our last meeting
… Last week there was the MPTS show in London. A few stands
there related to AI. A company from Germany, Phont, contacted
me, putting more dimensions into captions, such as emotion
… They seemed to be amenable to the idea of standardisation
… I asked them about cost of authoring, and they said it took a
long time to do manually, but their product uses AI to automate
… So although AI might not affect our mission directly, there's
extra information we might want to put in caption files that's
AI generated. Also AI processing to understand what's in media,
so having a profile for that, DAPT might be good for that.
Cyril: There's another contact we had, Captions with Intention.
Similar. Interesting to talk about that. I agree that authoring
is a key part
Gary: I was thinking of the same thing
Andreas: Other organisations run study missions to formulate
some use cases first. Then see if there's something to be done
Nigel: Chris, would this be a good idea for an MEIG study
mission?
Chris: MEIG has been asked the same question, I'm expecting to
have the same conversation there.
… Possibly on the agenda for the MEIG meeting the week after
next.
… That would be a broader conversation, not just about
captioning but media in general.
… I'm open to the idea of using MEIG as a place to cover that
stuff.
Nigel: I'm thinking MEIG could note the direction of travel and
identify any requirements.
… Those requirements could then come back into TTWG if
appropriate.
Chris: It would still be the same people doing the work, but in
a different context.
Nigel: It would be easier for non-members of W3C to participate
in the MEIG work.
Nigel: We could fold other organisations into the work, easier
to do there
Chris: And helps TTWG stay focused on its deliverables, and
MEIG is more exploratory
Nigel: That's a topic for TPAC then, either in MEIG or TTWG
Next meeting
Nigel: 4th June, [26]w3c/ttwg#340
[26] https://github.com/w3c/ttwg/issues/340
Meeting close
Nigel: Thanks everyone, we're at time. [adjourns meeting]
Summary of resolutions
1. [27]Auto-publish the TTML Profile Registry as a Note on
pull request merge, based on the usual TTWG Decision policy
applying to pull requests
Minutes manually created (not a transcript), formatted by
[28]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).
[28] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 21 May 2026 16:21:22 UTC