Meeting minutes
This meeting
Nigel: (reviews the agenda). Anything else to add, or make sure we cover?
Andreas: Start discussion about TPAC meeting this year
DAPT
Profile identifier and TTML registry w3c/dapt#248
github: w3c/
Nigel: In preparing a PR for the TTML profile registry for DAPT, I noticed we have two profile designators, for the content profile and the processor profile
… I don't recall why, though. And I notice we don't do this in TTML or IMSC, where we have a single profile designator that can be used for either
… Does anyone have any views? If we want to change to be a single profile designator, it would be a substantive change, requiring a new CRD
… But from the point of view of the profile registry, we'd have processor profiles with a different value than would appear in the DAPT documents. It's formally correct, but weird
… The media type and profile registry contains profile identifiers as short codes, then a URN as designator and a specification
<atai1> +1
Nigel: For DAPT we'd have a processor profile identifier and content profile identifier that are kind of for the same thing, but kind of not. Does that help us in general?
Andreas: How do we expect people to use the designators?
Nigel: In the TTML profile registry and the codecs parameter, it's less clear what they should do. They could put in a processor profile
… But they could specify a codecs value set to the content profile, even though the intent of that is to specify the kind of processor that can process the document, in which case you should use the processor profile
Andreas: Formally it's correct to handle DAPT in the same way
… No strong view, but it would be easier to follow a certain pattern
Nigel: It can be done either way. So you suggest easier to have a single designator that can be used as either?
Andreas: Yes, just follow what we did before and have one designator
… But i wouldn't oppose having two, if there are good arguments for that
Nigel: PRs 103 and 104 relate to this
… 103 moreso than 104
… I need to look more into the history of how we got here, but that's useful input, Andreas
… Any other views?
(nothing)
SUMMARY: @nigelmegitt to look again at #104, input from @cconcolato welcome, could be the best option is to use a single designator
IMSC 1.3
Nigel: The poll ends in 8 hours. Please vote if you haven't already
TTML Media Type Definition and Profile Registry
Nigel: There are 6 open issues and 5 PRs to address them. Please review those.
Nigel: There was a question about an IRT document that I think is now owned by ARD. We should update the contact information, any update Andreas?
Andreas: What's the timeline for doing it?
Nigel: It's only a note, so can be whenever
… I might create a separate issue for the contact info so we can merge the URL change
… (Reviews the PRs)
WebVTT
Gary: There's a call for consensus which passed. Next steps? Atsushi has a couple of PRs, but is anything else needed?
Atsushi: I updated a PR with the boilerplate. Once that's merged we can run streamlined publication of the CRD
Bikeshed TTWG boilerplate change PR
Gary: Once the bikeshed PR goes through, we can update the WebVTT PR to use that, which will unblock everything?
Atsushi: Yes, or we can merge the WebVTT one first
Nigel: The text that appears in CR for WebVTT, including the exit criteria, which is different to what we've had before. I think it's fine. It has more specific CR exit criteria in the charter
… Is anything more specific for what that means for WebVTT? I welcome views on whether it should say more about what it means in the context of WebVTT
Gary: It's generic text for the WG
Atsushi: We could remove this from the boilerplace and put the exit criteria in the spec itself
… I believe there's no strict requirement to say anything specific about the exit criteria in the boilerplate
Gary: Pointing to the charter sounds reasonable, rather than duplicating the text
Nigel: It's simpler to do that, which is good. Does any other CR do this? Will it cause any friction for other groups?
… Such as horizontal review groups, or AC reviewers, I mean
Atsushi: The AC reviews the charter itself, so following the charter should be fine. The standard checklist is quite welcome for browser specs
Nigel: We forgot to put exit criteria in IMSC, so we put them in the implementation report, and there weren't any issues
Atsushi: The implementation report will be reviewed when we go to AC review
Gary: To summarise, we need to review the bikeshed boilerplate PR. Once merged, that'll unblock the WebVTT spec changes
… Any other WebVTT topics to discuss?
(nothing)
Gary: One thing to mention, when James was summarising the attributes block discussion last time, he realised there are some edge cases we didn't address.
… For example, custom attribute names, and we decided to require a hyphen in them, but we didn't address whether we want to disallow names that start with a hyphen.
… There's a couple more, not major issues. But if anyone has time to review, or if you have thoughts now?
Nigel: It's a common pattern to prefix with a hypen, e.g., CSS property names, so it seems there's precedent for it
… Any lessons from that experience?
Gary: I don't see downsides. The only reason not to allow it is if we wanted a get attributes method to camel-case the attribute name
… But I don't think that's a strong case
Nigel: The expectation should be that the attribute keys should be portable into an HTML attribute
… What should the behaviour be if the WebVTT attribute has a syntax you can't use in an HTML attribute?
Gary: Use the JavaScript API. We've discussed a getAttributes() API
Nigel: Now I'm in two minds whether it's a good or a bad thing.
… There must be constraints on the JavaScript properties to avoid name conflicts
Gary: We could return a map object instead of a plain JS object. Good to look at how CSS handles properties starting with a hyphen
… But I'm inclined to allow such properties at the moment
… Or be more strict initially, and relax later
Nigel: In the absence of specific use cases, it seems that's the WebVTT way
Gary: Sounds good.
Gary: To summarise, look at how CSS handles camel casing of properties and whether it makes sense to use the same mechanism. Otherwise, start stricter and relax later
Impact of AI technologies on Timed Text Working Group's mission
Atsushi: W3C is gathering information on the impact of AI on WGs. Any comment, please add to the issue
Nigel: I'm a bit puzzled. (Reads the group's mission in the charter.)
… We're defining interchange formats, and we don't say anything about how they're produced or consumed. Nobody has asked for AI specific changes so far
… So from that point of view, there's no obvious change needed to our mission
… Interested to hear other views
Andreas: No particular proposal, but there have been discussion about metadata that should be carried with timed text, verify how timed text can be used in this context.
… One thing that's related, use timed text formats to transport timed metadata instead of timed text
… Not sure if we want to cover that use case, but people do use the formats in that way
Nigel: If something additional is needed related to AI, people would be asking for it. We haven't heard so far
Andreas: There may be requirements from people not in the group, though
… There was the question of interoperable metadata, e.g., the quality of generated text based on the AI engine. How TTML is used in this context could be improved, but not necesasrily something the group needs to work on. Would be good to verify that
Nigel: A question I'd have for Dom, who raised the issue, is how tightly scoped to the mission in the charter is the question? Or is he more interested in other things that may be relevant?
Atsushi: I believe the intent is to gather any related impact, so AI related metadata could be an impact. If it's not in the scope of the charter, we could list them as potential impacts
Chris: It may be broader, relating to production and consumption of timed text in general
Gary: One thing that could be helpful, is having mixed timed text and metadata content in the same file, which is doable in TTML now, but not in WebVTT
… We're adding attributes for file-level metadata, which could be used to note the content is AI generated
… But it doesn't change the group's mission
Nigel: I agree
Meeting close
Nigel: Thank you everyone, we're at time.
… Next meeting is in 2 weeks, 2026-05-21, agenda is w3c/ttwg#339
… [adjourns meeting]