{Minutes} TTWG Teleconference 2026-03-26

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


In plain text:

   [1]W3C

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


                Timed Text Working Group Teleconference

26 March 2026

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

      [2] https://www.w3.org/2026/03/12-tt-minutes.html

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

      [4] https://www.w3.org/2026/03/26-tt-irc


Attendees

   Present
          Andreas, Atsushi, Chris, Nigel, Pierre

   Regrets
          Cyril, Gary

   Chair
          Nigel

   Scribe
          nigel, cpn

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Delivering DAPT with audio recordings w3c/dapt#335
    3. [8]IMSC 1.3
         1. [9]Rec transition request
         2. [10]Issues and review feedback
    4. [11]AOB - Message Session
    5. [12]Meeting close

Meeting minutes

  This meeting

   Nigel: On DAPT, there's a discussion on carrying multiple
   related resources, I'd like to talk about

   Nigel: On IMSC, I've been looking at open issues, and updates
   on review feedback

   Nigel: Anything else?

   Chris: There's a new proposed addition to Media Session API, in
   Media WG

   Andreas: Nothing from me

  DAPT

    Delivering DAPT with audio recordings [13]w3c/dapt#335

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


   [14]Link to Discussion page

     [14] https://github.com/w3c/dapt/discussions/335


   Nigel: This is relates to the at-risk features in DAPT
   … If you've created a script, and audio recordings for it, that
   you need to deliver at the same time as the DAPT, the DAPT
   could embed them (as base 64, which is verbose)
   … or, you could have a package that you deliver with a DAPT
   document with audio recordings as separate files, referenced
   from the DAPT
   … or, you could host the audio recordings at a URL, and
   reference the URLs from the DAPT
   … Those are the main options. I sense that in a B2B
   client/supplier relationship, you wouldn't normally refer to a
   URL in the DAPT file, you'd want to deliver the assets
   … Which suggests a bundle or package format
   … I opened the discussion to get feedback, particularly in a
   broadcaster environment
   … I talked with technical architects at the BBC about this.
   They said base64 encoding sounds like a bad idea. They thought
   hosting at a URL in a delivery context, wouldn't be sensible,
   but it would in the context of delivery to the public
   … This leaves having a package format. What should that look
   like?
   … If a tar file, for example, could we have a hash value for
   the resource, to be able to check the integrity of the
   resources
   … They also raised the idea that you might want to send an
   update or amendment. For example, a script with 20 recordings
   and you just want to update one recording. Should you be able
   to send the one thing that change?
   … This idea exists in other places in the broadcast chain, and
   it can cause pain, if not implemented nicely

   Andreas: To transport audio inside the DAPT document seems not
   a good idea to me
   … If the concrete delivery workflow is in scope for DAPT
   itself. The DAPT needs the means to realise workflows, but how
   it's done is up to users
   … Is there much difference, you could use a relative URL for a
   file or an absolute URL to a server? Adding a hash reference
   for integrity would be a general question for any file
   referenced in the DAPT document

   Nigel: The hash document came from a reviewer who mentioned
   subresource integrity, in the context of HTML documents
   referencing other resources
   … We could adopt that, if it gets to Recommendation
   … Agree DAPT should have the tools needed.
   … If we think embedding in DAPT is not a good idea, we can make
   the spec smaller

   Pierre: +1

   <atai> +1

   Chris: I tend to think there should be just one way to do it,
   so referencing an external file

   Nigel: Then, there are data URLs that could also be used to
   embed
   … A follow up question, where should delivery specifications be
   defined? We could create a WG Note, or see what people do in
   practice, or leave to other organisations to write
   … I don't think we need anything normative, especially in the
   DAPT spec

   Andreas: The user community could discuss how to use the
   standard, and agree on best practices. Then, who'd publish?
   Similar to other specs. But in the past we haven't made
   recommendations, and left it to other organisations

   Nigel: Taking out the embedded audio at-risk feature, is
   getting higher on the to-do list

   Nigel: Anything else to add?

   (Nothing)

  IMSC 1.3

    Rec transition request

   Nigel: I issued the WG decision notification by email, to
   request transition
   … Since then, Atsushi has been looking at the feedback
   received, and the action we took
   … There's a concern we may have made a change to the document
   to address APA WG feedback, but we haven't had confirmation
   they're happy with it

   Atsushi: I haven't filed the transition request yet, but it's
   with me to do

   Nigel: Two things about the APA WG feedback. First, we did
   agree what kind of change would be appropriate, when we
   discussed at TPAC. Second, what we implemented was informative
   and editorial, and as discussed. So from my point of view,
   there's no reason to wait to send the transition request, when
   you have time

   Atsushi: I will find some time to raise the transition request

   Nigel: The other action was to raise a PR on w3c/ns. There's no
   rush to do that, and the transition request should come first

   [15]Raise PR on w3c/ns to add IMSC 1.3 namespace document

     [15] https://github.com/w3c/ttwg/issues/334


   Atsushi: I need to check, on what should be included in the
   document. Some discussion may follow on opening the PR, but
   I'll handle that
   … I don't think there's a fully well-documented requirement for
   the document contents to go in the namespace URI

   Nigel: Better to serve something than nothing

   Atsushi: Some tooling to retrieve the URIs or DTDs, but I don't
   think we have tooling in the timed text area

   Nigel: I don't think we need that, no

    Issues and review feedback

   [16]Nigel's comment on the APA WG comment about semantic layers

     [16] https://github.com/w3c/imsc/issues/524#issuecomment-4128606475


   Nigel: I took an action to summarise what the group thinks,
   based on our discussion
   … Any feedback on that or suggestions to change, we can look
   at. I think we feel nothing needed in IMSC. While semantic
   layers are useful, it's about finding the right place to do it

   Pierre: And having the right requirements. If there's a case
   for driving specific presentation semantics at playback, we'd
   definitely consider that

   <atsushi> or, we may ask them to move this issue from IMSC
   place into DAPT space or somewhere else??

   Nigel: There's one layering we do support, which is 'forced'.
   One proposal is to deprecate that, given there's a better way
   to do it

   Pierre: Also xml:lang is semantically relevant, because it
   allows renderers to pick the right font set, and track, and
   behaviour
   … I think until we have concrete use cases, it's not a valuable
   exercise

   Andreas: The last comment from APA WG was 5 years ago, so no
   activity since then?

   Nigel: We discussed it in person in September 2024, then again
   in TPAC 2025

   <atsushi> (suppose I should do as this rather than random
   comment.....)

   Nigel: Not sure how long to leave it...

   Pierre: I think we can close this

   Nigel: If people have things to add, they can re-open it or
   open a new issue

   github: [17]w3c/imsc#524

     [17] https://github.com/w3c/imsc/issues/524


   SUMMARY: Issue to be closed in a week, if no more comments

   github-bot, end topic

   Nigel: We have 4 open errata issues.

   Atsushi: Tooling requires open issues. We may change the
   tooling to look at open and closed issues. But as it's an old
   publication (these issues are errata for 1.1, and the errata
   document may be stable). Update the document with errrata, to
   be included in the Recommendation itself. Or we may create an
   errata from script into a static HTML document

   Nigel: I like the second option. We're not doing more work on
   IMSC 1.1, so very unlikely to have new errata

   Atsushi: Creating a static HTML document should be fine to do
   … Please create an issue to track this

   [18]Investigate moving the errata for imsc1.1 to a static HTML
   document w3c/ttwg#336

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


   Nigel: Anything else to discuss on IMSC?

   (Nothing)

  AOB - Message Session

   Chris: May be too soon to discuss, I'm flagging for attention.

   [19]w3c/mediasession#370

     [19] https://github.com/w3c/mediasession/issues/370


   Chris: This is a proposal coming from someone at Google to add
   transcripts to media session metadata.
   … Instead of custom captions, add transcripts to the media
   session metadata, in multiple languages etc.
   … Usable for a variety of purposes.
   … Proposal to gather feedback, before a follow-up PR.
   … No feedback so far, but he's created the PR anyway.
   … My feedback: Text Track is already a thing, why invent a new
   thing?
   … A browser can do this already if there are Text Tracks, and
   surface them for a Media Session.
   … I am hoping for more rationale.
   … I thought it relevant here that they're discussing the
   display of captions and transcripts
   … in a Media Session context, which is typically managed by the
   browser, including the UI,
   … and outside the document.
   … It raises lots of questions about the UI surface, and what
   the rendering looks like,
   … and how to control it.
   … There's no real detail behind this yet, which is why I
   thought it might be too early to flag.

   Nigel: When would the Media Session API be used?

   Chris: On a mobile device, for example, you're playing media
   and you're in the lock screen,
   … it can put up media transport controls.
   … The main use case is things like being able to
   play/pause/stop media playback without the page being visible,
   … or for handling keyboard keys for play/pause/stop, routing
   them to the current media element.
   … In general it is all about providing native controls for
   interacting with media specific content in the page.
   … My suggestion is to wait until we have more detail around
   rationale and then use that to ask more questions.

   Nigel: I agree, I don't understand why Text Track isn't
   suitable for this,
   … but if there are requirements that it doesn't meet, we should
   learn what they are!

   Chris: Related, there's a chapter information feature that was
   added to Media Session, which also
   … overlaps with Text Track @kind="chapter" but they want images
   as well as titles.
   … That's something you can do, set thumbnail images for the
   media, e.g. for the current track that's playing.
   … It's a separate but parallel chapters thing that you can also
   kind of do with Text Tracks already.

   Nigel: Yes, people already do thumbnails with Text Tracks but I
   don't think I've ever seen a Rec track
   … specification for it.

   Chris: Yes. Awaiting more explanation.

  Meeting close

   Nigel: Next meeting is 2026-04-23 [20]w3c/ttwg#332

     [20] https://github.com/w3c/ttwg/issues/332


   Nigel: The next call is in 4 week's time. There's a proposal to
   discuss a WebVTT issue
   … Thanks everyone [Adjourned]


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

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