- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 26 Feb 2026 17:13:38 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <4E38E917-D5CB-4ED2-89A9-3CE392F01D79@bbc.co.uk>
Thanks all for joining today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2026/02/26-tt-minutes.html
Please note that during our 2 upcoming March meetings Daylight Savings Time will apply in North America, making the meeting time 1 hour later there.
I propose that after DST comes into action in Europe at the end of March we adjust the UTC time of the calls by -1 hour.
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
26 February 2026
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2026/02/12-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/328
[4] https://www.w3.org/2026/02/26-tt-irc
Attendees
Present
Atsushi, Cyril, Nigel, Pierre
Regrets
Andreas, Gary
Chair
Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]Improve the ja character set per ARIB feedback
w3c/imsc#614
3. [7]IMSC 1.3 next steps
4. [8]DAPT Implementation Report
5. [9]March meeting times
6. [10]Meeting close
Meeting minutes
This meeting
Nigel: We have a bit on DAPT - just the implementation report.
… and on IMSC we just need to cover the ja character set
Pierre: Agree, we need to figure that out.
Nigel: In AOB we have meeting times in March when its DST in
north America, but not in Europe.
… Anything else for the agenda, or to make sure we cover?
no other business
Improve the ja character set per ARIB feedback [11]w3c/imsc#614
[11] https://github.com/w3c/imsc/issues/614
github: [12]w3c/imsc#614
[12] https://github.com/w3c/imsc/pull/614
Nigel: We had some good input that we processed last meeting.
What's the status?
Pierre: [shares screen showing preview of the pull request]
… Atsushi, what do you suggest?
Atsushi: ARIB TR document is some sort of operational manual
which records the current situation.
… It is not normative.
… It could be changed.
Pierre: Remove the TR-B39 sequence?
Atsushi: Maybe just note that these are operationally used but
not normative.
Pierre: suggests removing the explicit list and just
referencing TR-B39
Atsushi: the note also could apply to CJK ideographic
characters
Pierre: Make the reference to the ARIB TR a note?
Atsushi: Yes something like that, or suggest that IVS is used
for CJK and operationally used IVSes are
… used in ARIB.
Pierre: What's the down side of referencing ARIB-TR-B39?
Atsushi: It's a link from normative text to a non-normative
document.
Pierre: The entire annex is just a SHOULD not a SHALL.
Atsushi: SHOULD is normative too.
Pierre: It's useful though.
Atsushi: Yes, useful but the normative definition in ARIB STD
is that IVS may be used, but operationally
… characters listed in ARIB TR are the ones currently used.
Pierre: Exactly.
Atsushi: That's why I'm afraid that the TR definition may be
changed, so I want to turn that part into a non-normative note.
Pierre: Sure, [makes edit that the IVS is a Note.]
Pierre: Nigel, are you happy with this?
Nigel: Yes. Are there any other issues related to the ARIB ja
character set that we should be covering off here?
Pierre: [checks] I don't think so
Atsushi: Yes
Nigel: Great, let's go for it then.
Pierre: [pushes the change]
Nigel: The note about 10646 and Unicode - why is that in the ja
section? Oh, because it's only referenced in the ja character
set
Pierre: That's right
Atsushi: There are corrections that are only in the ISO spec.
… I approved the PR
Nigel: I approved it too
Pierre: I have to fix the merge conflicts then I'll merge the
PR.
SUMMARY: PR to be merged.
IMSC 1.3 next steps
Nigel: I think there's nothing more to do?
Pierre: Yes I think we're done
Nigel: So the Implementation Report is empty as expected.
… I can't recall when the exclusion period ends.
<atsushi> [13]https://www.w3.org/guide/transitions/
milestones.html?cr=2025-12-16
[13] https://www.w3.org/guide/transitions/milestones.html?cr=2025-12-16
Atsushi: The exclusion period has ended. We need an
implementation report and consensus for advancing,
… and AC review.
[14]IMSC 1.3 Implementation Report
[14] https://www.w3.org/wiki/TimedText/IMSC1_3_Implementation_Report
Nigel: The next step is for me to issue a call for consensus to
request transition to Rec on this basis,
… when the last pull request has been merged.
Atsushi: If we can issue a CfC within this week and have a
resolution in two weeks that could help me
… because I may possibly be offline for a while in the later
half of March.
Nigel: OK I'll aim to do that.
Pierre: PR Preview just started to work!
Nigel: Amazing, we can close off that other issue then.
Pierre: What do you need from me?
Nigel: I don't think anything - do we need to prep a Rec
version?
Atsushi: I believe you can use the /TR version for the CfC
Nigel: That's what I expect.
DAPT Implementation Report
[15]DAPT Implementation Report
[15] https://www.w3.org/wiki/TimedText/DAPT_Implementation_Report
Cyril: We've now implemented #daptOriginTimecode
Nigel: That's great.
… I've updated the IR with the new BBC validator link
Nigel: For the #daptOriginTimecode were you able to validate
it?
Cyril: Not yet - does your validator check it?
Nigel: Yes it does
Cyril: OK I can give it a try or you can
Nigel: From the Charter, there is some text we can lean on.
[16]Charter Success Criteria
[16] https://www.w3.org/2025/06/timed-text-wg-charter.html#success-criteria
Nigel: I'm proposing to bring some of that wording into the IR
as explanation, and separately list the
… different kinds of implementation that we have examples for.
… Hopefully that allows us to tell the story a bit more
clearly.
… Does that makes sense?
Cyril: Sure, yes.
Nigel: Anything else for us to cover on DAPT?
Cyril: How are you thinking about resolving the last features
that are not yet interoperable?
Nigel: What are they?
Cyril: The at risk features where we wanted implementation
feedback
Nigel: Those are two different things.
… The last non-interop feature in the IR is
#xmlLang-audio-nonMatching which is fairly minor.
… We either wait for an implementation that supports it,
… or we explain how there's no behaviour defined except for a
validator, and propose advancing with an exception based on the
scale of the issue.
… (which is tiny)
… For the at-risk features, that's different. Ideally I would
like to have more input.
… We could try to choose a minimum viable set and add in extra
options if people ask for them.
… Or we could include all the options and put a note on saying
that we may prune some of them in future
… versions based on usage and practice.
… I think as a rule choosing the minimum set and adding more
later is better.
Cyril: I agree, it minimises the tests and implementation tasks
too.
Nigel: OK the action is on me to go to AD providers and double
check with them what their
… preference is for including or referencing audio recordings.
Cyril: We could think also about workflows.
… If someone delivers to you a script and audio assets, how
would that work?
… Do you have a way to receive multiple linked assets somehow?
Nigel: Good question
Cyril: Pierre being here reminds me of IMF where there's a
manifest and a set of assets.
… You could supply a zip of all the assets for example,
… or include all the audio base64 encoded.
… Maybe the solution is to provide both and then see what
companies want to receive and what vendors support.
Nigel: That's a good thought process to go through. I will
check in with my colleagues in media supply as well,
… because they likely have preferences here.
… It is true that managing single files is easier if possible.
… But then, how can you validate that a zip includes all the
audio files referenced by the DAPT, say?
… Maybe that's another kind of validation.
Cyril: Right, and if you receive a zip and need to store it in
the asset management system, that's one thing.
… But if you have references you have the problem of what they
are relative to, what URL to put.
… If you put it in a zip file it can be relative to the path of
the document.
… But if it gets stored in the MAM you have to replace the URL
with something, an identifier or something
… like a proprietary URL.
Nigel: Yes that could be a problem.
Cyril: Do we care about playback of these files or just
transmission between a creator and a receiver?
… One of the use cases is sending to a client device for local
mixing.
… The technical requirements for sending the audio may be
different than from sending it to a platform.
Nigel: Yes, it may, that's right.
… There are a few approaches.
… One is to use relative URLs
… Another is to create a single audio track and use range
identifiers
… like clipBegin and clipEnd which are already available.
Cyril: or byte ranges
… It seems to me that it's hard for us to pick A or B, we have
to support both because different people will
… have different ways of doing things.
Nigel: [iterates through the at risk issues]
… For the values of encoding, I think we can just choose one -
presumably base64 would be the one.
Cyril: Yes it is the most deployed one.
Nigel: For the length attribute on data we can simply keep it
because it's useful
Cyril: for the referencing of resources, we could take the
approach of requiring <source> but restricting
… the number to 1 for now, with the option to add more later.
Nigel: That would work, yes.
… Would work for both embedded and external
… Or we could prohibit the src attribute and allow any number
of <source> elements and leave it to
… implementations how to deal with them.
March meeting times
Nigel: The proposal is to keep the current UTC time for our two
meetings in March,
… so that this call is an hour later in local time in north
America.
Cyril: Sure that works.
Nigel: OK let's do that, it keeps things the same everywhere
else.
Meeting close
Nigel: Thanks all, we're at time, let's adjourn.
[17]Next meeting is 2026-03-12 1600 UTC
[17] https://github.com/w3c/ttwg/issues/329
Nigel: [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[18]scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).
[18] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 26 February 2026 17:13:49 UTC