Meeting minutes
This meeting
Nigel: [iterates through agenda]
… Anything else for the agenda, or points to cover within the agenda?
Andreas: nothing from me
Atsushi: I don't have anything else
Apply streamlined publication to all of Note track documents
Nigel: As far as I know, this is complete and can come off the agenda from now on.
… The last piece of this was the TTML Profiles Registry Note, which should now be working.
… There are probably some really old WG Notes that we're not working on and haven't for years.
… We can ignore them unless we start working on them again, which is extremely unlikely.
DAPT
Test suite
Nigel: We have the structure of the test suite, and content
… Needs validating and checking, it may need some adjustment
… I haven't added links to the tests from the implementation report, that's still to do
… Some changes have happened during the review. Of the features we had, one was a presentation test, and all the others are validation tests
… Related to script event grouping. Cyril noticed that this is about the ability to nest divs, and TTML1 has a nested div feature
… Opened a feature to remove script event grouping and replace with nested div
… It's not a new feature in DAPT so it can be removed
… Just checking ... PR 304
Switch #scriptEventGrouping to #nested-div w3c/dapt#304
Nigel: This will also mean that the at-risk feature, #scriptEventGrouping, would need to change to #nested-div
… But I hope to close that without it being removed
… There's a separate PR on dapt-tests, w3c/dapt-tests#38 to remove those tests. That simplifies things, and makes CR exit criteria simpler to achieve as well
… That's good all round
Required #xmlId-div doesn't match other spec text w3c/dapt#297
Nigel: This got lost in different conversations. The way it was worded in the DAPT spec, the feature extension required every div element to have an xml:id attribute
… That was contrary to other text in the spec that they didn't have to, so it didn't make sense
… I proposed 3 resolutions to it. Remove the script event mapping, or to modify the scope of xmlId-div, or to look at how to identify whether it's a script event
… I thought the first option was the best way. I talked with Cyril last week, and he agreed
… That simplifies things, and this gave rise to PR #298
Remove #xmlId-div feature w3c/dapt#298
Nigel: These things together will simplify DAPT, the test suite, and the implementation report, so it's a positive. If you disagree, please let me know
Andreas: Makes sense to me
Nigel: There are 4 open PRs at the moment. There's an informative editorial one on pop prevention, Cyril seems happy with that. There's been some discussion with Simon Hailes who raised the issue
Add an informative section about pop prevention w3c/dapt#301
Nigel: Techniques to prevent audio pops, e.g., to have a steep ramp up, or having them start at zero, or having a guard
… Simon had a particular preference, and I don't want to be too prescriptive
Explicitly permit daptm:represents on tt, body, div, p and span w3c/dapt#300
Nigel: We had a previous PR, #294, where Andreas and Cyril agreed it had gone too far, adding it to p and span attributes. So I removed the support from p and span in the PR
… Separately I added another issue to add to p and span, #295, seems to make sense to allow script represents. It could lead to cases people might not expect
… You could have a p element corresponding to a Text, saying it represents one thing and a span inside that says it represents something else
… So you'd have to compute what it represents
… Imagine an AD that contains both a description of things in the video image, also some written text. They could have different represents values on them
… But you might want the description so people understand they're different things, and recorded in one go
… In that case you'd have to create multiple script events for the thing supposed to be read out together, and adjust the timings
… Hard to predict that, so you'd have to fix it after recording. It's overly complicated. You'd want to use a single audio recording
… Hope this makes sense!
Andreas: I looked at the PR based on previous issues on clarity of the inheritance, to clarify where represents can sit. I didn't notice you added a note that represents can be on the span level. Is that right?
Nigel: Yes
Andreas: Makes sense to me, given the use case
… It can be applied further down, to Text objects
Nigel: Yes, it has been updated
… It should be clear
… It's allowed on p as well
Andreas: OK
Nigel: Thanks. As all the PRs reach their 2 week review period, we'll close them off. If there are related tests, I'll fix those
… Once they're all done, we should publish a new CR snapshot
PROPOSAL: When the currently open pull requests have been closed (by merging or otherwise), request transition to CRS
Atsushi: Wide review? When something changes we need to request wide review for CRS publication
… We have several small substantive changes as far as I know
Nigel: We've updated the substantive changes document
Atsushi: And for the open PRs...
Nigel: We should do a diff between the updated version and the previous CRS. It's worth checking
… Do we need to request horizontal review on the delta?
Atsushi: Just need to request a delta review with a list of substantive changes, or list of PRs, not a full review
Nigel: So following the HR process, for a delta
Atsushi: We need to say it's specifically a delta and point to the changes. I don't expect any groups to have concerns
Nigel: Do we need to do this before requesting the CR snapshort, or do at the same time?
Atsushi: CRS publication has several requirements, including getting wide review. Until we show wide review has been completed, the transition request won't be validated
Nigel: So we should do it sooner rather than later
Atsushi: As a delta review, it shouldn't take long
Nigel: To clarify, you said wide review. Do we need to share with industry more widely, or just with our stakeholders?
Atsushi: Horizontal review groups, but the group wants, we can ask liaisons
Nigel: Don't want to wait too long. I could send a message or write a blog post that's public
Nigel: Anything else to raise on DAPT?
(nothing)
IMSC 1.3
FPWD publication
Nigel: I sent a CfC two weeks ago. I'm not aware of any objections. I asked for comments in favour of the proposal, and Glenn replied
… I'm in favour, does anyone want to express a view?
Pierre: I fully support it!
Nigel: Any other views?
(nothing)
CfC to publish IMSC 1.3 Text as a FPWD
RESOLUTION: Publish IMSC Text Profile 1.3 as a First Public Working Draft
Nigel: What happens next?
Atsushi: When that's sent to public-tt, I'll send the transition request
Nigel: I assume we want automatic publication of a new WD? Let's do that
… Any editorial work needed to prepare the draft?
Atsushi: At the moment, with manual publication there are some additional configurations to do
… After that I'll submit a PR for automated publication
… We should use github.io for the ED
Nigel: Any concerns, Pierre?
Pierre: No. It should be pretty unremarkable, not needing testing as it's in TTML2, we've removed a feature. We should move quickly
… We should prepare an implementation report
Nigel: Publish the CRS, file horizontal review request issues, explain the difference between versions
Pierre: I can write text, and if you can file the HR reviews?
… Add a target date to receive feedback. It should be a minor revision, so don't want people to worry it'll be a lot of work
Nigel: Did we decide to allow changes in this version? It's worth flagging to people
Atsushi: PLH sent email to chairs that many WGs use CRS rather than updateable Recs due to the work involved
Nigel: Yes, there's editorial complexity. Some think it's onerous. The level of change for us with superscript/subscript, updatable Rec would have been easier
… It's a tooling issue
… Easier to do that for small increments. Or maybe people need the incrementing version numbers. Would be intersting feedback. IMSC is referenced by lots of other SDOs
Pierre: I'll create a blurb and send to you, Nigel. Let's get it out as soon as possible
Other admin
Nigel: For IMSC 1.3. PR preview is fixed. there's a PR for the w3c ns repo to add the namespace documents, what needs to be done?
TPAC 2025 planning
Nigel: The draft schedule is broadly OK for us. It may not allow people interested in all media topics to be there for just the last 2 or first 2 days
… Audio WG has some clashes, if that affects you, let us know
… One of the Audio WG chairs is getting back to the TPAC planners
… let us know if you have other concerns about the schedule
… TTWG's main meetings are on the Tuesday
… MEIG joint meeting on Monday, 4 sessions on Tuesday, Thursday first session is MEIG / APA / TTWG joint meeting. Media WG meets on Friday
Nigel: Could be a breakout session on DataCue and TextTrackCue, which is in WICG at the moment
Chris: We may have a call prior to TPAC to try to move it forwards too.
… Depending on whether we can have a conversation between now and then, the outcome
… of that may change what we do at TPAC, or we might want to leave it until TPAC to start
… the conversation, then I can go back to Rob with that.
… His interest in narrowly on DataCue, so if there's a broader conversation around MSE and
… Timed Text Tracks and the whole integration piece then that's a TPAC thing.
… We started it last year and not much has happened since then.
Nigel: Yes, I think they need separate sessions.
Chris: Yes, the DataCue is about the interface and its relationship to TextTrackCue and
… Apple's proposal to introduce cue and cue-background attributes on TextTrackCue,
… then there's a separate conversation about MSE handling of cues in ISOBMFF files.
… Or other media formats.
Meeting Close
Nigel: Thanks all, let's adjourn, we are at time. Next meeting in 2 weeks, w3c/ttwg#311
… [adjourns meeting]