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 w3c/dapt#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
Raise PR on w3c/ns to add IMSC 1.3 namespace document
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
Nigel's comment on the APA WG comment about semantic layers
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: w3c/
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
Investigate moving the errata for imsc1.1 to a static HTML document w3c/ttwg#336
Nigel: Anything else to discuss on IMSC?
(Nothing)
AOB - Message Session
Chris: May be too soon to discuss, I'm flagging for attention.
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 w3c/
Nigel: The next call is in 4 week's time. There's a proposal to discuss a WebVTT issue
… Thanks everyone [Adjourned]