Meeting minutes
This meeting
Nigel: DAPT and IMSC1.3. Some progress to report on CR publication for DAPT. Some issues on both to discuss. Anything else?
(nothing)
DAPT
CR publication status
Atsushi: I have made a transition request, we're just waiting for approval
CR Request for DAPT (Transition Request issue)
Atsushi: I hope that we can publish during next week
Nigel: The final horizontal review, for security, is completing. Issues raised said they don't need to hold up CR, but they may want changes before going to Rec
… This is good news. Any questions or comments?
(nothing)
Add an XSD w3c/dapt#273
github: w3c/
Nigel: This PR is to add an XSD, but there seem to be some challenges for some people getting it to work.
… It works fine in the tool I used, Oxygen
… Last time we discussed in December, I had action item to add a validator script to use the XSD, and update the readme
… I tried it but it didn't work, the TTML2 XSD has a circular reference pattern, where files import or include other files that include the original file
… The tool I used seemed to be able to navigate that, but other tools see it as an error
… Has anyone tried anything?
… I could try refactoring so we make it DAPT specific and not use TTML2 at all. It could flag things up as unrecognised though. I'm not keen to redo it all
SUMMARY: Continue looking at options for DAPT validation
Detail Security Considerations Section w3c/dapt#281
github: w3c/
Nigel: The reviewer asked why the spec includes the TTML2 security considerations. That seems fine
… Also, refer to threats or attacks related to XML
… I think we have protections by refusing to allow things like XML entities
… These should already be described in TTML
… We can say something, to show we've considered it
… Also, discussion of the threat model
… Subresource integrity was mentioned as something to check. A URL to an external resource, e.g, an audio clip, you could put a cryptographic hash in the source document, then the player computes the hash and compares
… In the discussion, I pointed out that would be annoying during authoring, but as a final step in publication it could be useful
… Not against it in principle, but it feels like solving a problem I haven't seen in the real world. But maybe others have...
… We can consider whether to add to the spec or not
Cyril: How is this different to issue 282, which is also about the integrity model?
Nigel: 281 is about drafting the threat model, and 282 is about a mechanism for identifying such an attack has happened
… I think it all makes sense. Any other thoughts or comments?
(nothing)
SUMMARY: Draft a pull request addressing the issue
IMSC 1.3
Nigel: Thank you for the progress on this
Pierre: Issue 551 is assigned to you
Nigel: I'll look at it, draft a PR
… The issue is about meeting WCAG success criteria in 1.1.1.
Nigel: Other open issues to cover for 1.3, Pierre?
Pierre: Those labelled 1.3 are the ones to be dealt with
Nigel: We should all check the open issues for IMSC 1.3, if any need including or not, to flag them on the list
APA WG comment: semantic layers w3c/imsc#524
github: w3c/
Nigel: Am I right that, people have different files for different resources? So the problem moves to the signalling arena
Pierre: On the terminal side that's true. But on authoring side, force display, different files for different tracks
… A challenge that's been pointed out is, when you have non forced content on, you have more space so you might change the forced content accordingly
… So there's a creative reason to have separate tracks
… The trend I see is to have separate tracks
Nigel: In terms of semantic labelling, this is present in DAPT, so there's a potential production path where DAPT is used as an authoring stage, then the relevant content is extracted from the DAPT layer into a single purpose subtitle or caption track
… then layer on styling as a next step, at which point you have an IMSC document
… I'm nervous about being too prescriptive about arranging production workflows
Pierre: It seems an unbounded issue, no concrete proposal, no timeline
… Your note says further discussion needed. So we should either discuss or defer the issue
Nigel: The key question seems to be whether some normative statement is needed here
… force display is normative, and clear what the required player behaviour is
… But with an extensible list of layers, what is the player supposed to do?
Pierre: force display was created at a time when the selection of a particular experience should be done in the ISMC presentation engine. That turned out not to be a great idea
… So this seems left from a bygone era, rather than being something for the future
… Having separate tracks is an accurate observation
Nigel: People who want spoken subtitles, they want indication of the language and to trigger a text to speech system
… We don't have formal semantics for supporting that, but it does get asked for
… Solution to add metadata to allow that information to be tracked. Then it's a player behaviour to decide to speak the translations, but they can also conformantly play the caption track
Pierre: There's no impetus today to have a generic system. So address if and when a proposal comes forward for a generic scheme?
… We could respond by saying we don't have use cases that support creating a generic scheme at this point for IMSC 1.3
Nigel: You can use ttm:role attribute as generic scheme already. What's missing is to define player semantics
Pierre: And for that there's no industry standard. It's been a point of friction
… If APA were to come up with a generic scheme, it might be great
Nigel: Yes
Nigel: There are two decisions to make. Do we deprecate force-content? Do we reference the ability to label particular subtitles (or parts of) as occupying different roles? And if we do, does APA want to define a specific set?
Pierre: I recommend we do nothing, as we don't have concrete use cases?
Nigel: Spoken subtitles are in use in parts of Europe now
… They have some additional signalling, I think as part of DVB profile
… Are you saying it would be better to have representation in this group for this?
Pierre: Yes. There are definitely use cases, but this is about IMSC specifically
Nigel: I can take an action to contact people
Pierre: Not sure that would address the APA concerns though, in this issue, as the request is more for a generic system
Nigel: And what we have are two very specific systems
Pierre: I think the answer is that we don't have the information needed to come up with a generic scheme
… So I suggest going back to APA to say we'll defer it
SUMMARY: Discussed in TTWG call 2025-02-13, more input from APA WG needed to describe the generic scheme they have in mind
Introduction: include an example pair of documents, one Text and one Image profile w3c/imsc#553
Nigel: A lot of the positive feedback we got on DAPT was about having examples in the Introduction, which helps people understand it
Pierre: The problem it is, it depends who you ask. Different people has different perspective on how IMSC should be used, so I'm very reluctant to come up with an example of how it should be used
Nigel: Not sure I understand the concern. The examples don't have to show every possible usage pattern
… Could show the structure of the document, how to do timing, positioning and styling
Pierre: We have MDN and published tutorials
Pierre: We could include an informative link.
Nigel: I don't think we need a tutorial, just enough context for people to understand the spec. Happy to add a link as well
… I'd be happy to come up with a concrete proposal
Pierre: Sounds good
Namespace updates
Atsushi: Not had time to look at this yet, but will start
AOB: Charter review
Atsushi: We have all horizontal replies except security. If you want to hear from other organisations, e.g., liaisons, please proceed
… I may initiate AC review shortly, so if you want to request reviews from external organisations, please do shortly
Nigel: I don't think we need external reviews
Meeting close
Nigel: Next meeting is on 27 Feb, same time. Let me or Gary know if you have agenda topics
Nigel: Thanks everyone. Until then, see you on GitHub! [adjourns meeting]