W3C

Timed Text Working Group Teleconference

18 January 2024

Attendees

Present
Andreas, Atsushi, Chris_Needham, Cyril, Gary, Matt, Mike, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
cpn, nigel

Meeting minutes

This meeting

Nigel: Two main things today, IMSC HRM and transition request to PR, and DAPT topics for discussion. Anything else to add?

(nothing)

IMSC HRM

Nigel: I raised a CfC on a pull request that Pierre opened. We discussed in last meeting, but made some last minute editorial changes
… e.g., to definitions and references to external specs. I sent the CfC a week ago, the decision period ends on 25th January
… This is an opportunity to raise discussion points. The implementation report is important to show we've met CR exit criteria
… Atsushi has reviewed, and made some changes, making it easier for others outside the group to follow
… Decision to be made about publication date.

CfC Email 2024-01-18

Pull request of Proposed Recommendation version

Atsushi: The transition reviews are held on Fridays, so if we send the request on 25 or 26, considering the required period, the review might come in February
… After approval, publication will be on a Tuesday or Thursday

Pierre: There's a CR end date that we may have to set manually
… I guess that would be next week

Nigel: The CR end date says 23/07/20, maybe that was from the first CR?

Atsushi: Each snapshot has a review opportunity, so that period should be 60 days

Nigel: Looking at the history, first CR snapshot was 22 June 2023 and that sets a no-earlier-than date of 2023-07-20 so that's where that date comes from
… The other date that's more concerning is 11 January 2024. I don't know where that comes from
… That's like an AC review close date

Atsushi: There's a 4 week comment period
… for Proposed Recommendation there are several dates. AC review should be 4 weeks

<atsushi> https://w3c.github.io/spec-releases/milestones/?pr=2024-01-30

Nigel: May need setting manually, if we can't set the date in ReSpec. Atsushi, is that something you can do?

Pierre: It would help me if you can put the dates we want in the pull request, and I'll look at the ReSpec

<atsushi> https://w3c.github.io/imsc-hrm/spec/imsc-hrm.html?specStatus=PR

Atsushi: Changing status and publication should work. The date would be set automatically

Nigel: Any thoughts or comments on the substance of the report, before we make a WG decision to request transition to PR?

Chris: I had a look at the implementation report and have two questions.
… One is: does the report need to show traceability to spec sections?
… The report has a comprehensive list of test cases where each test case describes what it is testing
… but I did not see a link to section numbers or feature definitions in the spec.
… Second question: when we discussed the Charter and there was a lot of focus on the CR Exit Criteria,
… was there a concern raised about the use of human generated content?
… I note the test suite is human authored content. Maybe I'm misremembering.
… I think one of the reviewers wanted to see machine generated content being tested.

Nigel: The test suite content is fine to be human authored. I don't think anyone was arguing otherwise
… It shows deliberate authoring to test features in the spec. That's normal
… Those synthetic tests are useful for verifying a valid implementation is behaving correctly
… What people wanted in the tests is on the authoring side tooling - so if we're asserting that the presence of large amounts of content meet the authoring requirements of HRM,
… what they wanted to see was an implementation on the authoring side. It mattered not that the content was human generated, rather that a human was using a software tool
… When there are two sides: a producer and a consumer, and here the consumer is the validator, and the spec defines requirements for the data passing over the interface. Some reviewers wanted us to show there's a software implementation as producer

Implementation Report

Chris: Thanks, that makes sense. And the point about traceability?

Pierre: When we generated the unit tests, the goal was to get coverage of the spec. It should cover the entire spec, but the report doesn't have an explicit mapping
… If we feel it's important, we can add it

Nigel: The report says each test contains a description. So two concerns here: checking that the test suite adequately tests the requirements, and then understanding what each test exercises
… In the past specs like TTML define feature designators that are in the IR as pointers to what that test exercises. May be a lot of work, but I guess it's possible to add descriptions to the table

Pierre: There may not be a mapping between sections and test. Chris, do you think the descriptions in the tests are sufficient?

Chris: I think the descriptions are good so I would say they are sufficient.
… I understand from reading the specification that there is not a simple 1:1 mapping.
… I'm not here to try to ask you to do extra work!
… Just pre-empting potential feedback.

Nigel: Wondering if it's possible to do a simple copy/paste, but may make the table unwieldy

Pierre: Does the table have a link to the document itself? Then it would be trivial to click through to see the descriptions
… I also want to avoid duplicating information, things can get out of sync in the future

Nigel: Do you think that [linking the test filenames to the files in the repo] would help AC reviewers?

Chris: Yes I think that would be a helpful addition.
… I also note that in the interest of avoiding duplication, the pass tests also correspond to a fail test,
… and the description is not always in both tests of the pair.

Nigel: So we could put the pass and fail test in a single row

Pierre: We could add full description to the pass test, and link them. But I wouldn't combine them into the same row, as there may not always be both
… But happy to add links, and descriptions to the pass files

Nigel: Anyone else have questions?

(none)

Nigel: Atsushi, is it a good idea for you to start preparing the transition request? It might expose other questions you have

Atsushi: I can do that, but I don't think I have any further items
… There's a Changes section from last CR, no need for another horizontal review. We're now in CfC, wide review should be finished, so I don't think there's anything else than preparing the IR report

<atsushi> https://w3c.github.io/imsc-hrm/spec/imsc-hrm.html?specStatus=PR&publishDate=2024-01-30&prEnd=2024-02-27

Nigel: You have one week to raise questions, but if noone comments, I'll declare consensus for a WG Decision and we can request the transition after that.

Atsushi: Some Respec configuration changes, for /TR publication (in IRC above)

Nigel: That's fine, of course

Nigel: The pull request changes the spec status already, but we don't know when the transition review will happen or how long

Pierre: Please comment in the PR and I'm happy to add those dates
… It would be great if the release on GitHub would match the publication date, so I'd like to have the dates in the PR and make the changes
… I'll work on the IR and test suite descriptions
… Thank you all for your help with this

Action for Pierre to add descriptions to tests where they're missing

DAPT

Nigel: Last publication was on 23 December. All the work on language was merged
… Some additional PRs have been opened or commented on since
… No issues labeled as agenda, so looks like we're progressing to CR. Cyril, anything to raise on DAPT?

Cyril: Not really.

Nigel: Issues remaining are mainly editorial. There are some questions listed as CR must-have, and some are choices, especially wrt embedded audio resources, referenced audio, and encodings
… Absent any implementation experience to help answer those, maybe the thing to do is list those as at-risk. If we get experience to settle on a preferred subset, we can remove the others
… Does that sound like a reasonable plan?

Cyril: I think so. We should try to resolves all the ones we can, though.

Nigel: I expect you and I will continue work on the PRs, Cyril

Cyril: I mentioned a few weeks ago I was working on open sourcing a library and open content. This is progressing, hope to announce something soon, Feb or March.
… We should have a variant of Neflix Meridian content, with dubbing and AD

Nigel: That's really positive, thanks

Next meeting and meeting close

Nigel: If there's no other business, we can close the meeting
… Thank you everybody

Nigel: I have a conflict in 2 weeks time
… We could have a meeting if need be, may need Gary to chair

Gary: I don't know if I can

Nigel: We may not have much to discuss, so let's see what we have

Nigel: For now, let's adjourn. Thank you everyone. [adjourns meeting]

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).