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
Latest publication REC 2026-05-21
Nigel: We published Rec today. Congratulations and thanks everybody for your work on it
Pierre: Thanks everybody for helping push it along
… Could discuss IMSC Image Profile today?
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?
Pull request to revert to ED from Rec
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
TTML Profile Registry entry for IMSC 1.3
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 w3c/dapt#248
github: w3c/
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
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, w3c/ttwg#340
Meeting close
Nigel: Thanks everyone, we're at time. [adjourns meeting]