W3C

Timed Text Working Group Teleconference

25 April 2024

Attendees

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

Meeting minutes

This meeting

Nigel: Today's agenda:
… * IMSC-HRM Rec publication
… * DAPT agenda items
… * AOB from Cyril about the recent live captioning industry event
… * AOB from Nigel about the UK regulator Ofcom's updated Access Services Best Practice Guidelines
… Anything else for the agenda?

group: nothing else

IMSC-HRM

Nigel: Great news - as you'll have seen on emails, we published the Recommendation today.

IMSC-HRM Rec 2024-04-25

Nigel: Big thank you to everyone for contributing to this,
… and special shout out to Pierre for Editing.

Pierre: Thanks to Movielabs for supporting me in this.
… I plan to publicise this early next week, let me know if you want to join in.
… My experience when testing it is it's really useful for making sure that one's library
… does not contain subtitle files with errors or that are too complex. Thanks everybody.

Atsushi: Congratulations.

Pierre: I'd like to note that at the end we had two implementations!
… Thanks Nigel, I think that was good, we found a bunch of bugs.

Nigel: It really validated the usual approach of having more than one implementation, that experience.
… Pierre, I saw you merged w3c/imsc-hrm#80 which closed w3c/imsc-hrm#79, and published a release.

Rec release on GitHub

Nigel: Thank you for that. This concludes the work on this specification for the time being.

Pierre: Indeed.

Nigel: Which raises the question: what next?
… When we began this refactoring process we said we wanted to remove the HRM text from the IMSC specifications.
… That's the next question - do we go ahead and do that change on its own, or wait until there are other
… substantive changes to make and then go ahead and do it together?

Pierre: My preference is to wait.

Nigel: That's fine for me - one thing that would change the picture would be if someone came to us
… and said they wanted to reference IMSC-HRM separately in their requirements.

Pierre: Yes, that would fall into the same category as any "can't live with it" issue in IMSC.
… I will open an issue on IMSC to factor out the HRM so that we don't forget it.

Nigel: Anything else to raise about IMSC-HRM?

No other matters

DAPT

Nigel: We have one item on the agenda, but I also want to raise another point about ttm:role

Add informative section about mapping from TTML to the DAPT data model w3c/dapt#216

github: w3c/dapt#216

Nigel: We discussed this last call and I began working on the edits to the pull request,
… but then realised we hadn't concluded properly on something where two mutually exclusive views
… had been presented.

Nigel: [summarises w3c/dapt#216 (comment) ]
… From Cyril's response I think it's clear that for vocabulary in DAPT or TTML namespaces, or any
… namespace included in the spec, processors should not write out vocabulary relating to features they don't support.
… My next question is: what about stuff in completely different namespaces?
… Like locally defined metadata.

Pierre: Unless the spec defines a place in the model for metadata, with enough semantics that
… the processor can do something with it without knowing its contents, the safest thing is for the processor
… to prune them altogether.

Nigel: Such a place might be as a child of the <metadata> element for example.

Pierre: You might say that in head/metadata, temporally, any metadata applies to the whole document.
… They might still put in some average word count, say, so a processor that doesn't know it could
… update the document and invalidate it.
… From a spec perspective it makes sense to prune all unknown vocabulary. It's the best approach.

Cyril: A few points. I may have responded too quickly! I'm thinking about changing my mind.
… With an MP4 file, if there are boxes I don't understand, do I expect a processor to remove them?
… You would remove the declaration of the features not understood.
… In TTML, you would definitely remove the contentProfiles that aren't supported.
… Does it mean you have to remove everything?
… You could remove it, but if you leave it in, then you're not claiming its validity.
… The entity that would process the document could decide to keep, say, a word count element,
… but would remove the contentProfiles declaration.
… Secondly, when you rewrite a document, it's two steps: parsing and then writing.
… What's the difference here? You could write valid documents against the specifications you declare validity for.
… Option 1 was "MUST omit" - I think it is probably too strong.

Andreas: I'm a bit reluctant if we recommend at all to prune unknown vocabulary especially in foreign namespaces,
… because it could remove some benefits of extending TTML documents with data, especially metadata.
… From the user point of view, what could you expect if foreign namespace metadata is in the document,
… and it goes through an implementation not controlled by the user.
… You could say it is implementation dependent, but in the best case it stays where it was before.
… Then the user needs to live with the fact that it may not be meaningful any more.
… If we recommend pruning, then metadata would only survive implementations that understand it.
… I think that's too strong a requirement.

Pierre: Just to clarify, I'm saying this strictly from a specification conformance perspective.
… I expect implementations to do whatever.

Cyril: What does it mean though, because if the implementation doesn't meet the spec then it's not compliant.

Pierre: Say there's a presentation processor, pruning unknown vocabulary can be tested.
… If you feed a presentation processor two documents, one with foreign vocab and one without, you
… would expect the same outcome.
… If there is a conformance for a translation or transport processor...

Nigel: That's what we're talking about

Pierre: From my experience in TTML and MXF, I've only seen pain in trying to keep around things that
… you don't know what they are.
… From a conformance standpoint it's either a MUST or nothing.

Nigel: The point about contentProfiles was agreed, there was no doubt about that.
… We are talking about a document that reads and writes DAPT documents, rather than a presentation processor.
… A suggestion I have based on the above is as follows:
… If there is any feature or vocabulary that has some semantic that means it could be invalidated by being
… "passed through" then the definer of that vocabulary better make a profile for it and have that appear in
… contentProfiles when output by a processor that supports it.
… Other vocabulary that is just inside any metadata element can be passed through and no assumptions
… about validity should be made.
… I think we should prune any unsupported vocabulary in namespaces listed in DAPT though.
… The third part is that a processor that does support some extra profile and receives a document that
… doesn't claim conformance to that profile but does contain vocabulary relating to it needs to take extra
… validation steps and may need to modify it.
… That last point is hard to write a testable specification conformance rule for.

Nigel: Does that make any sense?

Cyril: What can we say about the definer of vocabulary making a profile?

Nigel: We can make a note recommending that people do this.

Cyril: That's fine.

Andreas: I think at least the first two options seem fine to me, but they're more recommendations
… to the author than the processor, right?

Nigel: From this I can define processor behaviour, as follows:
… 1. Never include in ttp:contentProfile profiles which the processor does not support.
… 2. Foreign namespace vocabulary in <metadata> elements should be preserved
… 3. Non-foreign namespace vocabulary that is not supported MUST be removed
… And then there's advice too, for authors as you suggest.

Andreas: Yes I think those are processor requirements.

Pierre: Number 2 is not testable because of the SHOULD.
… By the way, I think that's what will happen in practice, but from a spec perspective it is not testable.

Andreas: I think that it's implementation dependent, what happens, but whatever keyword you use
… it is a recommendation to keep where possible. In some cases it may not be possible,
… because a semantically identical document has its structure changed, and the parent of the metadata element
… was removed while doing that.

Nigel: That last point is a whole other headache - I think with DAPT it should not happen but I guess it is possible.

Pierre: The only alternative I can think of is to preserve vocabulary but if you put it in a particular
… location then it has limited impact. It's going to be fragile I think.

Nigel: There's a good test case there for us to think about which is what if you take a DAPT document
… and add styling in to make it an IMSC document.

Cyril: I was thinking the same thing.
… I'm wondering if, once you start making a subtitle out of a DAPT document, you've forked it and you're
… in the subtitling space - I'm not sure you'd want to go back to the DAPT processor for anything.
… It's a one-way door I would say.

Pierre: One thing just occurred: does the spec really need to define a transformation processor?

Nigel: Validation processors are a subset of transformation processors.

Pierre: Just for validation it's okay to prune everything that's unknown.
… Maybe just don't define transformation processor other than validation processor so we don't need this?

Nigel: That's where I started out when we began thinking about this.

Nigel: I think I have enough to go ahead and try editing here, and see how that works out.

SUMMARY: @nigelmegitt to attempt to edit this into the pull request; everyone else to think about the semantics for including TTML styling vocabulary.

AOB - Captioning industry event

Cyril: Three of us, Pierre, myself and Andreas were there.
… There will be a report posted soon, summarising what happened.
… The gist of it is that it was a very successful event, with a lot of people attending
… from various parts of the industry, from studios to caption vendors to universities - very broad.
… There will be follow-ups I think, possibly in Europe so others can have a chance to attend.
… The outcome is probably that at least for live streaming the technologies we have in place are not
… sufficient to address a global market, Asia, Europe, US.
… It's probably not a lack of standards, more a lack of guidelines and good practices.
… There was a strong support for TTML in the room, people saying TTML could solve all of it.
… That's my quick summary.

Pierre: I'm about to start writing the report so I'll withhold my final opinion!
… Something that struck me was an intense desire in the room to do more interop testing.
… From a high level user/ecosystem standpoint there's a perception that there isn't enough interop testing being done.
… What's fed at one end of the chain comes out very different at the other end.
… The strongest immediate desire in the room, among other things, was to make progress with interop.

Andreas: One main outcome was everyone was interested in following up and keeping the community,
… finding a forum to collaborate and work on these issues.

Cyril: Maybe for another time, we should think about how this working group can get more feedback
… on its activities.

Pierre: Thinking out loud, many folk who attended would never attend TTWG because it's down in the details
… for them - that's a good thing! There might need to be a higher level forum where operational and practical
… issues are discussed. I think there was agreement that the core standards exist, but it's how to use them
… that generated the friction.
… Ultimately how the industry works with this group is super important I think.

Nigel: Thank you for the great summary, and for telling us about this.

AOB - UK regulator Ofcom's recent updates

Ofcom news article

Nigel: Quick AOB - the UK regulator Ofcom updated its Access Services Code (the requirements) and
… the associated Best Practice Guidelines.
… The goal of the work I think is to pave the way for UK regulation of the accessibility of video media, whether
… on broadcast or online.
… There's a UK government bill in progress which will bring big streamers into regulatory control, for example,
… and Ofcom will have to do that.

Nigel: If the UK's approach is of interest, it's worth checking out that page and following the links.

Meeting close

Nigel: Thanks everyone, next meeting in 2 weeks as usual. [adjourns meeting]

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