- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 19 Jun 2025 16:16:27 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <03839BC1-88A7-4AE1-BF82-857A2AC4B5C8@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2025/06/19-tt-minutes.html
We made 1 resolution, at the conclusion of a CfC:
RESOLUTION: Remove Image Profile from IMSC 1.3 and create an IMSC 1.3 Text Profile as a standalone document
This will be enacted in w3c/imsc#603<https://github.com/w3c/imsc/issues/603> . The review period for this decision has concluded, since it was done as a CfC on a Proposal from the previous meeting, 2 weeks ago, and no objections were received.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
19 June 2025
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2025/06/05-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/309
[4] https://www.w3.org/2025/06/19-tt-irc
Attendees
Present
Atsushi, Chris_Needham, Cyril, Nigel, Pierre
Regrets
Andreas, Gary
Chair
Nigel
Scribe
nigel, cpn
Contents
1. [5]This meeting
2. [6]IMSC 1.3
1. [7]Drop Image Profile
3. [8]DAPT
1. [9]Test Suite
2. [10]Required #xmlId-div doesn't match other spec text
w3c/dapt#297
3. [11]Rename #scriptRepresents to
#scriptRepresents-root? w3c/dapt#296
4. [12]Should we allow Represents on Text objects?
w3c/dapt#295
4. [13]TPAC 2025 planning
5. [14]AOB - Next meeting
6. [15]Meeting close
7. [16]Summary of resolutions
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> [17]DAPT is on CVS (www)
[17] https://github.com/w3c/ns/pull/4#issuecomment-2982203887
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 [18]imsc#603, thank you for Pierre for all
the work. I've reviewed, it looks good
[18] https://github.com/w3c/imsc/issues/603
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 [19]w3c/dapt#297
[19] https://github.com/w3c/dapt/issues/297
github: [20]w3c/dapt#297
[20] https://github.com/w3c/dapt/issues/297
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? [21]w3c/dapt#296
[21] https://github.com/w3c/dapt/issues/296
github: [22]w3c/dapt#296
[22] https://github.com/w3c/dapt/issues/296
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? [23]w3c/dapt#295
[23] https://github.com/w3c/dapt/issues/295
github: [24]w3c/dapt#295
[24] https://github.com/w3c/dapt/issues/295
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> [25]three meeting entries for now
[25] https://github.com/w3c/tpac2025-meetings/issues?q=is:issue state:open timed text
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: [26]Next meeting is 2025-06-19
[26] https://github.com/w3c/ttwg/issues/309
Meeting close
Nigel: Thanks everyone [adjourns meeting]
Summary of resolutions
1. [27]Remove Image Profile from IMSC 1.3 and create an IMSC
1.3 Text Profile as a standalone document
Minutes manually created (not a transcript), formatted by
[28]scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).
[28] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 19 June 2025 16:16:37 UTC