Meeting minutes
This meeting
Nigel: [reviews the agenda]
… Anything to add, or points to cover in those items?
(nothing)
Republication of png-hdr-pq WG Note
Nigel: PR 13 adds a warning note to point to PNG 3rd edition, in 2023. We haven't published an updated Note since then.
… The Note was published in 2017, and the Editor's Draft is 2023
… There are some broken references to fix too
… Proposal is to republish this note to include the most recent edits
Pierre: Sounds good
Chris: +1
PROPOSAL: Republish the PNG-HDR-PQ note to include the most recent edits
Nigel: Any objections?
no objections
RESOLUTION: Republish the PNG-HDR-PQ note to include the most recent edits
Nigel: Needs an editor, to fix some ReSpec errors
Pierre: I don't mind doing that
Pierre: I created w3c/
Comment about this resolution in the issue
Nigel: Anything else on this topic?
Pierre: After updating, how do we publish?
Apply streamlined publication to all of Note track documents
Nigel: We don't have auto-publication set up for Note track documents
… Atsushi asked if we wanted to do that
PROPOSAL: Apply streamlined publication to all Note track documents so that merging pull requests will trigger republication automatically
Nigel: Any reasons not to do this?
(none raised)
RESOLUTION: Apply streamlined publication to all Note track documents so that merging pull requests will trigger republication automatically
Nigel: Atsushi, could you set this up for us please, starting with the PNG HDR PQ Note?
Atsushi: Will do
DAPT
Transition DAPT requirements WG draft Note as formal Note?
DAPT Requirements WG Draft Note
PROPOSAL: Publish DAPT Requirements as a WG Note
Nigel: I think this is a useful document, and having a Note will be better to reference from the spec
… Any concerns or questions?
Chris: Sounds good to me
RESOLUTION: Publish DAPT Requirements as a WG Note
Test suite
Nigel: Lots of the issues have been updated in dapt-tests recently
Nigel: I opened an issue for every feature that's listed in the implementation report, assuming we need tests for all of them
… More recently, I've gone through the spec text and written some detail about what test resources we need
… For example, valid and invalid cases for Profile Root
… I expect, for all these features there are no presentation semantics to test, but there are validity cases
… We'd expect any validator to confirm validity of valid tests, and invalidity of invalid tests
… There's a question about authoring tools, that aren't validators
… For those, I'd suggest a manual exercise to make the authoring tool generate output that stresses each feature should have that output be valid in a validator,
… where the validator also passes the validation test for that feature
… Essentially, if the validator seems to work, and if the authoring tool stresses the feature, and the validator validates that output, we can say the authoring tool did it's job
… Does that make sense?
Cyril: Yes. An authoring tool could exercise multiple features, so we don't need the same granularity
Nigel: Yes
Atsushi: What is WPT doing, for CSS, should be fine for us also
Nigel: CSS usually has visual output you can test against, but in our case we don't have that
Nigel: I've done 8 of them so far, just the analysis of test resources expected. Others welcome to contribute
… My plan is to keep going through them, there are 9 left
Cyril: To confirm, we're not going to try to create tests for combinations of invalid features?
Nigel: I think we should keep them as separate as we can
Cyril: The tests shouldn't be just for passing the exit criteria, they should be also more useful for implementers
… Maybe we can augment the test suite in the future
Nigel: Yes. Then we might want to discuss partitioning the files into CR exit criteria tests vs more general tests, or keep them all together
Cyril: I'd keep them all together, then the CR exit criteria tests is a subset
Nigel: That's fine
… There's one place in the spec where you can't avoid testing related features together: represents and scriptRepresents
… We should keep the tests to the smallest test resource that does the job
Cyril: I was thinking of using an AI agent to generate tests
Nigel: As long as we can verify them, OK
Cyril: Just as a way to learn using the AI agent ;-)
Nigel: Anything else on tests and implementation reports to cover?
Cyril: Netflix will contribute its implementation, more an authoring tool / transformation processor than a validator
… I don't have a coverage for AD parts. Do you have something for those parts?
Nigel: Yes, could be a third party one rather than BBC
… I could probably do a validator as well
… Different approaches there: augmenting the current TTT one, written in Java
Pierre: There's the toy validator created for TTML2, in JS, sandflow/
… It's simple to extend
… If you're interested in this one, happy work with you on it
Cyril: To recap, in terms of passing exit criteria, if we have a validator, and a Netflix and BBC/Third party implementation, that passes the features, we're good to go?
Nigel: I think so
… One of the implementers I spoke to said they may have something by IBC in September
… May need to be quicker than that to include in the implementation report
Cyril: Better to have implementation feedback, in case they have suggested changes
<nigel> +1
Atsushi: Implementation would be judged feature by feature, we have a two implementation requirement
Nigel: Yes, the exit criteria is feature by feature, rather than each implementation having to be complete with respect to all the features
Nigel: Anything else on DAPT tests or implementation reports?
(nothing)
IMSC 1.3
Outgoing liaisons regarding IMSC 1.3 and Image Profile
Nigel: You'll have seen all the outgoing liaisons I've sent
… We have some responses, some about updating our liaison contact names
… We've also asked on social media
… Anything to say about early feedback?
Pierre: So far, it's been a surprise that nobody seems to have been using image profile across an ecosystem. It's used internally within some systems, but that's different
… No suggestion anyone is interested in modifying or maintaining it
… This is the private feedback I've received
Pierre: I'd be happy to keep Image Profile in IMSC 1.3 if someone wants to see changes or maintain it
Nigel: Just want to record I have the same view, even though I proposed removing it.
Pierre: Part of the challenge is it's hard to maintain if we don't know how people want to use it
… Nothing so far really
… We should give ourselves a deadline
Nigel: Some groups have a long response cycle...
Pierre: June?
Nigel: That's almost 3 months, a reasonable period, given some groups' response cycle
Pierre: We should aim to publish by end of this year, so go to CR soon
Atsushi: From W3C staff point of view, we might want to get more attention from external organisations, e.g., SMPTE
… so I'd like to write some statement to TAG or W3C management to invite points of view, an email about the collaboration points
Nigel: I wrote to SMPTE
Atsushi: Recently we got a small amount of interaction from W3C members. That means we could have smaller amount of interest among W3C members
… We may need to gain more member interaction on the timed text work
… Our output is quite stable, so updating activity should be quite low compared to other API development work in W3C
Nigel: What's the impact on IMSC 1.3?
Atsushi: There's some pressure that we need to gain impact from members of interest in our activity, or say new development is important for the public interest
… This kind of public interest should be questioned for our new work in the chartering process. Allow time for development within W3C. I hope we could gain more interest from external parties to our activities in the near future
Nigel: I'm not clear what action we might take right now
… Coming back to the liaisons, I sent them on 3 April. We have a call on 5 June, so let's use that to assess responses and come to a conclusion regarding image profile
Atsushi: That should be fine, as I understand
Nigel: Anything else about the liaisons?
(nothing)
Refer ARIB STD-B69 or STD-B62?
Nigel: Atsushi asked which ARIB document we should reference. Is there an easy answer?
Atsushi: I had a question from ARIB about the charter document. IMSC 1.3 defines ARIB STD-B62 but the charter and liaison statement mentions ARIB STD-B69, so they're wondering which is to be referenced from IMSC 1.3
… They said originally we referred to B62 for everything, but were surprised the liaison statement referred to B69, and also that it's in the draft charter
Nigel: B62 has coding of closed captions
Atsushi: Both refer to our specification. I haven't checked the differences between them
… They wonder if we want to update it to B69 from B62?
Nigel: I looked it up and STD-B69 is EXCHANGE FORMAT OF THE DIGITAL CLOSED CAPTION FILE FOR DIGITAL TELEVISION BROADCASTING SYSTEM
Nigel: Whereas STD-B62 is MULTIMEDIA CODING SPECIFICATION FOR DIGITAL BROADCASTING
Nigel: I don't mind, we can refer to both, it doesn't have to be one or the other
… The latest B62 looks more recent than B69
… No strong opinion
Pierre: Can we file an issue?
Atsushi: If we do that, I'd like to send an email to them about it. It's not a big issue, but we need to confirm
Nigel: Atsushi, could you please raise an issue in the IMSC repo?
Atsushi: Yes
AOB
Nigel: The AC review of the TTWG charter has opened. Please encourage your AC rep to vote
Atsushi: Yes, we want responses from all the participating organisations
Chris: I've responded already
Atsushi: I've asked the Japanese organisations to vote, but some might abstain
Nigel: Next meeting in 2 weeks on 2025-05-08
[adjourned]