{Minutes} TTWG Teleconference 2026-05-07

Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2026/05/07-tt-minutes.html


In plain text:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

07 May 2026

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2026/04/23-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/333

      [4] https://www.w3.org/2026/05/07-tt-irc


Attendees

   Present
          Andreas, Atsushi, Chris_Needham, Gary, Nigel, Pierre

   Regrets
          none

   Chair
          Gary, Nigel

   Scribe
          nigel, cpn

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Profile identifier and TTML registry w3c/dapt#248
    3. [8]IMSC 1.3
    4. [9]TTML Media Type Definition and Profile Registry
    5. [10]WebVTT
    6. [11]Impact of AI technologies on Timed Text Working Group's
       mission
    7. [12]Meeting close

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 [13]w3c/dapt#248

     [13] https://github.com/w3c/dapt/issues/248


   github: [14]w3c/dapt#248

     [14] https://github.com/w3c/dapt/issues/248


   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.

   [15]Pull Requests

     [15] https://github.com/w3c/tt-profile-registry/pulls


   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

   [16]Bikeshed TTWG boilerplate change PR

     [16] https://github.com/speced/bikeshed-boilerplate/pull/197

   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

   [17]Team request for input

     [17] https://github.com/w3c/webai-roadmap/issues/37


   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
   [18]w3c/ttwg#339
   … [adjourns meeting]

     [18] https://github.com/w3c/ttwg/issues/339




    Minutes manually created (not a transcript), formatted by
    [19]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

     [19] https://w3c.github.io/scribe2/scribedoc.html