W3C

Timed Text Working Group Teleconference

27 February 2025

Attendees

Present
Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
Andreas, Chris_Needham
Chair
Gary, Nigel
Scribe
nigel

Meeting minutes

This meeting

Nigel: Today we have some DAPT and IMSC stuff
… Any other business, or points to make sure we cover within those topics?

Gary: AOB for timezone - next meeting will get us into the DST shenanigans
… March 9 in the US, so 3 or 4 weeks difference

DAPT

Nigel: No issues or pulls listed for the agenda.
… We do have a transition request.
… for CR publication.

Transition request for DAPT

Atsushi: The decision should be made on Friday 28th February.
… I cued myself to prepare for a March 5th publication.

Nigel: Do you need anything from us?

Atsushi: No, I may open a PR for the final up to date tweaks but I don't believe there is anything
… to be done by the WG for publication.

Nigel: I wondered about comms, blog posts etc.

Atsushi: I should be able to handle those.

Nigel: For most stuff you will just update the existing CR?

Atsushi: Yes

Nigel: Good news, good to get there.

Atsushi: Thank you for your patience with the formal procedure.

Nigel: Any questions about this?

Implementation Report

DAPT Implementation Report

Nigel: I had the action to update it to add recently added features and at risk features.
… I have now done that.
… The added feature was #descType.
… I started looking again at the XSD earlier, and have hit an error I don't understand yet.
… The next big step for us is to create test material for all the DAPT features.

Cyril: FYI re DAPT.
… Last week I attended Mile High Video in Denver.
… There were a few presentations about dubbing, mainly academics.
… For example changing the speed of speech to accommodate dubbing.
… I was able to promote DAPT and encourage implementation feedback.

Nigel: Sounds good!

IMSC 1.3

Nigel: One pull request flagged for the agenda, re namespaces.
… Anything else to cover?

Pierre: We could do #551 too.

Update namespace documents w3c/imsc#589

github: w3c/imsc#589

Nigel: Two things to cover.
… First is can we publish the namespace documents?

Atsushi: I have not reached a conclusion myself about what should be in the namespace documents.
… For this moment what I can do is open pull requests to the W3C namespace document repo,
… and ask for review or comment or suggestion etc. on the PR.
… I am not sure if there should be any negotiation or knowledge of the existing documents,
… but I personally have not enough knowledge at this moment.
… I am now just tending to opening the pull request and asking for review including from plh and others
… for meeting namespace documents.
… If you don't have any comments about the contents then let me get comments from the wider
… team including plh or others who worked on DTD and XML before.

Nigel: OK

Atsushi: I understand that the definitions are not necessary for us since there is almost no tool
… who are querying the namespace documents on the fly.
… I heard there are some toolchains e.g. for RDF and JSON-LD that access a namespace definition file
… every time they have to validate something. If there are tools like that in IMSC space...

Pierre: There's no such tool

Atsushi: I believe we just need some static HTML.

Pierre: What do you need to make progress?

Atsushi: To be honest this is the first time I'm updating namespace documents.

Nigel: See for example the TTML2 one:

https://www.w3.org/ns/ttml/

Atsushi: Best I can do is learn from existing documents.

Nigel: This is maybe much simpler than you are thinking!
… It just needs to be a resource you get when you dereference the namespace URL.

Atsushi: Let me open the pull request

<atsushi> himorin/w3c-ns#1

Nigel: This is where we got to 1 month ago when we discussed it. The action is the same.

Atsushi: Let me try and I will consult if I get any comments.
… I can prepare the similar thing for IMSC immediately.
… If this one for DAPT is accepted then I could immediately create the IMSC one.

Nigel: I think the IMSC one is more urgent.

Atsushi: I will prepare one for IMSC in parallel to this.

Nigel: OK, then the next thing to consider is the substantive content of the PR.
… I had two proposals. One was to add fragment IDs.

Pierre: [Omitting fragment identifiers] was by design.
… The fragment identifier is not part of the URI, it's a UA behaviour.
… As I recall the discussion many moons ago, the fragment is not part of the namespace when you
… resolve it.
… This is all because we are using URIs that happen to be HTTP URLs, and the fragment is not part of the URI
… that is being dereferenced.
… The HTTP GET request does not include the fragment ID, it's only the UA that looks for that id
… when the document is loaded.

Nigel: Then I would change my proposal to list the namespaces with fragment IDs in the HTML documents.

Pierre: That's needless duplication of the Namespace section in the specification.
… The sole purpose is to get a reference back from the namespace into the defining document.
… Once you get that non-machine-readable namespace document, you get told where to go to find
… the meaning of the namespace requested.
… I don't want to duplicate. I want these documents to be as simple as possible.

Nigel: I think it's a weird user journey to put in one of the namespaces from the IMSC spec,
… then get taken to a page that says "this spec defines that namespace" but doesn't actually list
… any of the strings in the spec, which all have fragment identifiers.

Pierre: We could change the wording to encompass all fragment identifier suffixes too.

Nigel: That could work, yes.

Pierre: We need to get the correct wording for that concept.

Nigel: OK, should we wordsmith that now?

Pierre: Probably should, since we're here and it's the last issue.

Nigel: Now we have:
… "The namespace http://www.w3.org/ns/ttml/profile/imsc1 is specified by ..."

Pierre: [looks up RFC3986]
… "secondary resource" is one term used in RFC3986.
… "The fragment identifier part allows ..."

Nigel: So we could say "The namespace http://www.w3.org/ns/ttml/profile/imsc1 and all secondary resources identified by additional fragment identifiers are specified by ..."

Pierre: Yes that's good
… [implements that in the PR]

Pierre: You had another orthogonal concern.

Nigel: Yes, mapping the versions in namespaces to the IMSC document versions,
… IMSC 1.1 Image namespace is an outlier pointing to IMSC 1.2 spec.

Pierre: We want to point people to 1.2 because we improved the spec document compared to 1.1
… even if we didn't make substantive changes.

Nigel: OK that's a strong enough argument for me.

Pierre: And you were a strong proponent of pointing people to the latest version of the spec.

Nigel: True!

Pierre: I agree it's annoying to have a version number that points you to a spec with a different version
… number that then points you back to another one!

Nigel: OK I think we have enough to resolve on this.

SUMMARY: @himorin to open pull request to implement this PR change; Keep the existing version mappings as in this PR now; update the IMSC namespace doc to include secondary resources.

Pierre: I've done the secondary resource change.

Nigel: I've approved it.

Pierre: Should I merge it?

Nigel: Yes merge it, and if there's feedback let's handle in a different ticket.

Pierre: Thank you everybody

Atsushi: I can use this merge to support this with W3C team in discussions if needed.

Wording of example for WCAG SC 1.1.1 w3c/imsc#551

github: w3c/imsc#551

Nigel: I raised a suggestion to resolve the APA comment by removing Image Profile from IMSC in 1.3

Pierre: I'm not philosophically opposed to this.
… I'm not sure it's the best thing, it would require time to inform the community,
… and I'm not sure we have the time this time around.
… That's why I'm not super excited.
… But for a later iteration, we should probably open an issue specifically on this,
… so that we remember it for v.next, but for now just stick to revising the note, which I think is great.

Nigel: Ah, good that you liked the proposal.
… What kind of conversations do we need to have with the community about this?

Pierre: We need to tell people we are stopping work on image profile.
… But we're also saying IMSC 1.3 might be a version we can never obsolete, because it
… is the last version supporting Image Profile.
… We have to remember that the last version of IMSC containing Image Profile should not be
… obsoleted because even though it might not be up to date for Text Profile, for Image Profile
… it might be the right one.
… Or we split the documents.

Gary: Is it possible to add a non-normative note to the Image Profile section saying we're considering
… removing it from future editions.

Pierre: I found one of those notes in the current version of the document and we never acted on them.

Gary: Maybe update the note to make it more prominent and follow through.
… That could be the signal to notify the community.

Pierre: I think we should just talk about it.

Gary: That too. It would be good to have it in the spec.
… An "official" documentation for it.

Pierre: If it helps you, I'm happy to do it.
… I think we should post a message on the SMPTE, W3C, EBU, DASH-IF reflectors etc.

Gary: Community outreach is more important.

Pierre: If we get no feedback maybe we should do it now.

Gary: I guess what are the timelines for IMSC 1.3 and how long do we want to wait.

Pierre: Someone who really cares about it should respond quickly.
… If we compose a standard message that says we're considering no longer maintaining
… IMSC Image Profile and it will be forever the one in IMSC 1.2 or IMSC 1.3, let us know what you think.
… And we go to the various groups with that, and convey that message, and
… nobody complains and everyone supports, I think I'd be comfortable to remove it.
… But the second someone says they use it extensively and want to add something, then
… it sets a longer discussion going. But if nobody complains in a defined timeline, I'd be comfortable removing it.

Nigel: My argument in favour of your proposal Pierre is that we have no proposals for any feature changes
… relating to Image Profile, but we have already diluted it somewhat compared to 1.2 by removing the
… HRM applicability. So anyone currently using Image Profile is subject to the HRM constraints,
… whereas if we keep Image Profile in 1.3 and publish it, then it isn't clear whether an Image Profile
… document meets the HRM constraints or not. So if there's industry support, removing Image profile
… now would be cleaner, and would make 1.2 the last version with Image Profile support.

SUMMARY: @nigelmegitt to open new issue for dropping Image Profile, and to open a pull request with proposed note text; consider industry messaging offline.

Meeting close

Nigel: We're over time - Gary do you have a proposal for the DST change?

Gary: Last time we stuck with UTC so the meeting was an hour later in the US.

Nigel: That works for me if it works for everyone else.
… [adjourns meeting]

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).