Meeting minutes
This meeting
Nigel: (Reviews the agenda) Anything else to cover?
(nothing)
IMSC 1.3
Nigel: Can we fix the PR preview?
Atsushi: I checked the configuration but didn't find any error
Nigel: Please continue
Nigel: Is the namespace work all done?
Atsushi: I've changed it in CVS and have opened a different PR but I'm not sure who will review it.
Nigel: OK, so there's some work to do to finish this.
<atsushi> DAPT is on CVS (www)
Atsushi: I will work on IMSC namespace documents in the same way
Drop Image Profile
Nigel: Last meeting, and in email, I sent a CfC to drop image profile, based on the feedback we've had
… There's a specific proposal
PROPOSAL: Remove Image Profile from IMSC 1.3 and create an IMSC 1.3 Text Profile as a standalone document
Nigel: No comments or objections received, so I'd like to mark this as a resolution
… Last chance for any comments...
RESOLUTION: Remove Image Profile from IMSC 1.3 and create an IMSC 1.3 Text Profile as a standalone document
Nigel: Looking at PR imsc#603, thank you for Pierre for all the work. I've reviewed, it looks good
Pierre: There is one thing. Your last comment on divs with id attributes. One thing PNG did, preserve links to the undated version of the IMSC url
… If some has a link to a fragment in IMSC 1.2 using the undated link, if it's a link to an image profile provision, it will link to the explanation that the IMSC profile has been removed
… It's not completely foolproof, but not a bad practice
… I can add an HTML comment to explain why they're there
Nigel: That's neat, good idea to add a comment
Pierre: I followed the PNG spec as an example
Nigel: The thing is, you'd want it before the heading of the section, otherwise it might scroll the heading out of view. I guess it makes sense
… Anything else to discuss?
Pierre: Other things are minor, I'm accepting your comments now. I think we're good for FPWD
… The comment about reordering things in a section, I'll create a separate issue, it's not related to removing image profile, so can address with other editorial improvements for FPWD
Nigel: The table formatting is probably the most significant, it's now difficult to look at
Pierre: I tried a couple of things, I lean towards making it as close to the previous IMSC version as we can, in case we put image profile back
… I've tried to remove without refactoring as much as possible
Nigel: About the CSS styles, though
Pierre: Yes, we should look at that after FPWD
Nigel: I dealt with this in DAPT, so have a look at the DAPT source and you could copy that
… There's a style section at the top of the document that adds table styling. I think it might be that
Pierre: Ok, I'll take care of that
Nigel: Another thing was dark mode, I found it's changed underneath me so have had to take action to fix it
Pierre: Should we merge this today and set a date for FPWD, e.g., in 2 weeks?
Nigel: We agreed to remove image profile, it's been open more than 2 weeks, has approval, so meets our process requirements
… I'll re-review and approve, then we can merge
Pierre: Thanks
… Do we need to run a CfC for FPWD?
Nigel: Let's do that
… Looking at issues for IMSC 1.3, there's a response from APA, I have an action to include only one text example document with example rendering
… There's one more issue about force display and visibility hidden. Do we do that in FPWD or not?
… We can still do FPWD if there are changes to make later
Pierre: Absolutely
Nigel: After merging, we should check the status of the other PR and close if already done
… Did you look at the respec reference issues?
Pierre: Yes, just a case of refreshing windows, there's caching going on
… There are lots of errors when you first load, then they go away on refresh. Same when opening locally
Nigel: So the action is for me to run a CfC to publish IMSC1.3 as FPWD, once this is merged
… Anything else on IMSC
(nothing)
DAPT
Test Suite
Nigel: I've made some good progress. I pushed structural stuff to the test suite, license, readme, etc
… Also, for all the issues in the DAPT tests repo that I could, I opened PRs to add tests
… In the past, for IMSC HRM, rather than reviewing 1 by 1, we put all the tests in a repo and asked if there are any issues with that
… Could do that again. I'd like a branch with all those PRs in it so I can work on a validator
Cyril: I don't have a problem if you merge all the PRs
Nigel: I'll do that, it makes things easier
Required #xmlId-div doesn't match other spec text w3c/dapt#297
github: w3c/
Nigel: We've discussed before, but it's now a pain
… We considered some way of identifying if a div is a script event but didn't agree anything
… xmlId-div has disposition required. Because we don't have a way to scope it to a script event, it applies to all divs
… But the spec is clear elsewhere that they don't have to have xmlId
… So you can't create tests with xmlId. I think we don't need this extension feature. All the normative requirements we need are in the script event mapping feature, so I propose removing xmlId-div
… I created a PR to show what that looks like. Any thoughts?
Cyril: Your proposal sounds fine, I don't have a problem removing the feature extension
… Still not convinced by requiring the xmlId on divs to identify that a div represents a script event
Nigel: It doesn't do that, it doesn't say every div with an xmlId has to be a script event.
Cyril: So how to identify a script event?
Nigel: I think the script event mapping says that if it's a div with xmlId and no child divs, it's a script event
Cyril: I don't feel comfortable, I'd rather have a script event id or something
Nigel: We can still propose if it's useful. My sense is that there isn't a problem that needs solving with this
… But could leave to implementation experience
Cyril: No objection to remove the feature itself. Can approve the PR
Nigel: Once we merge the PR to remove the feature, that unblocks adding those tests
… Any other thoughts on this?
(nothing)
SUMMARY: Follow usual PR process to merge the PR and close the issue if no objections
Rename #scriptRepresents to #scriptRepresents-root? w3c/dapt#296
github: w3c/
Nigel: This renaming is a consistency thing. When there's an extension feature that relates to a particular element, we include the element name
… This one is an odd one out. So it's an editorial change to rename it
Cyril: Agree
Nigel: Anyone else?
(nothing)
SUMMARY: @nigelmegitt to change the name as per the issue - editorial change
Should we allow Represents on Text objects? w3c/dapt#295
github: w3c/
Nigel: This came out of #294 where Andreas and Cyril pointed out that this isn't allowed in the model. But I think may be it should.
… Can one script event contain text that represents different things. For example, in audio description would you put one script event that both describes something in the image and reads some on-screen text
… If there's limited time available. Would you do that for any transcription or dubbing workflows?
… It seemed a good idea at the time, but I'm less sure now
Cyril: Trying to remember the use cases I had where Represents is useful on a span. In Netflix content we have annotations that we put at the div level when they're actually span level
… For example, one annotation is when speakers are saying the title of the movie in the movie. When you translate it, you want it to be consistent
… It would be dialog.mainTitle or something like that. But I thought we needed to highlight which part of the script event, as it's a smaller granularity
Nigel: So we think there is a use cases, and would make it easier if we do this
… Should we open a PR for it?
Cyril: We should discuss, if you put Represents on the span part, why not create two or three span parts and put on each? You could have one script event with the entire text of the script, if you don't care about timing, and do Represents at the span level
… Don't want to encourage that. Maybe we should include some guidance to split the events first
Nigel: I agree, this is there if you have to use it. If you want some continuously flowing representation of a script, e.g., a recording, and you can't predict the timings, there could be a disjoint at the script event level when you play it back, because you didn't get the timing exactly right
… Makes sense to add guidance
… Any other thoughts on this?
(nothing)
Nigel: This unlocks PR #294. Andreas sent me a message to say he's happy with the solution in #294. He hasn't approved the PR though
… If we can approve #294 it gives a good basis to resolve the other issue.
Cyril: I'll check. I don't see a problem approving it
Nigel: Thanks, that would be helpful
SUMMARY: @nigelmegitt to open a pull request for this
TPAC 2025 planning
Nigel: We discussed with APA WG and have requested joint meetings with them and MEIG
<atsushi> three meeting entries for now
Nigel: I didn't know what to do with the AD CG. There could be a joint meeting with TTWG to look at DAPT and status of implementation issues
… I sent email to the CG. I suggested it for the Monday and Tuesday. My request to members is to focus on the beginning of the week so people don't have to stay longer than needed
… It's a good time to talk about user groups as well
… Speaking of which, there's a CCSUBS meeting on Thursday next week. DAPT is on the agenda,15 minutes to talk about user groups
Chris: I think it's good you're organising around the Monday and Tuesday.
… MediaWG is organising around the Thursday and Friday so there should be no overlap
… for those who want to attend both.
… Cyril, I may send you an email about timed text tracks in MP4 because MediaWG
… had a whole discussion about this and needed more expertise.
Cyril: Happy to help
Nigel: This was in the context of mapping data models entities between MP4 and MSE,
… for things that may or may not be the same!
AOB - Next meeting
Nigel: Next meeting is 2025-06-19
Meeting close
Nigel: Thanks everyone [adjourns meeting]