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.
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.
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/
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/
… 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
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]