- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 3 Jul 2025 16:34:16 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <E048C650-315F-46F0-B90A-B7182F07E5F1@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2025/07/03-tt-minutes.html
Following the Call for Consensus to request publication of IMSC 1.3 Text two weeks ago, we confirmed this as a Working Group Decision:
RESOLUTION<https://www.w3.org/2025/07/03-tt-minutes.html#1ea9>: Publish IMSC Text Profile 1.3 as a First Public Working Draft
Since this followed a CfC there is no further review period under our Decision Policy.
Those minutes in plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
03 July 2025
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2025/06/19-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/310
[4] https://www.w3.org/2025/07/03-tt-irc
Attendees
Present
Andreas, Atsushi, Chris_Needham, Nigel, Pierre
Regrets
Cyril, Gary
Chair
Nigel
Scribe
nigel, cpn
Contents
1. [5]This meeting
2. [6]Apply streamlined publication to all of Note track
documents
3. [7]DAPT
1. [8]Test suite
4. [9]IMSC 1.3
1. [10]FPWD publication
2. [11]Other admin
5. [12]TPAC 2025 planning
6. [13]Meeting Close
7. [14]Summary of resolutions
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
[15]Switch #scriptEventGrouping to #nested-div w3c/dapt#304
[15] https://github.com/w3c/dapt/pull/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, [16]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
[16] https://github.com/w3c/dapt-tests/issues/38
[17]Required #xmlId-div doesn't match other spec text
w3c/dapt#297
[17] https://github.com/w3c/dapt/issues/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
[18]Remove #xmlId-div feature w3c/dapt#298
[18] https://github.com/w3c/dapt/pull/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
[19]Add an informative section about pop prevention
w3c/dapt#301
[19] https://github.com/w3c/dapt/pull/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
[20]Explicitly permit daptm:represents on tt, body, div, p and
span w3c/dapt#300
[20] https://github.com/w3c/dapt/pull/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)
[21]CfC to publish IMSC 1.3 Text as a FPWD
[21] https://lists.w3.org/Archives/Public/public-tt/2025Jun/0013.html
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
[22]Draft schedule for TPAC 2025
[22] https://www.w3.org/2025/06/tpac2025-schedule-20250627.html
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, [23]w3c/ttwg#311
… [adjourns meeting]
[23] https://github.com/w3c/ttwg/issues/311
Summary of resolutions
1. [24]Publish IMSC Text Profile 1.3 as a First Public Working
Draft
Minutes manually created (not a transcript), formatted by
[25]scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).
[25] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 3 July 2025 16:34:33 UTC