- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 25 Apr 2024 16:17:01 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <1C2E2BA2-F927-47EB-9F8A-3D08ECB4BD59@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2024/04/25-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
25 April 2024
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2024/04/11-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/280
[4] https://www.w3.org/2024/04/25-tt-irc
Attendees
Present
Andreas, Atsushi, Cyril, Matt, Nigel, Pierre
Regrets
Chris_Needham, Gary
Chair
Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]IMSC-HRM
3. [7]DAPT
1. [8]Add informative section about mapping from TTML to
the DAPT data model w3c/dapt#216
4. [9]AOB - Captioning industry event
5. [10]AOB - UK regulator Ofcom's recent updates
6. [11]Meeting close
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.
[12]IMSC-HRM Rec 2024-04-25
[12] https://www.w3.org/TR/2024/REC-imsc-hrm-20240425/
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 [13]w3c/imsc-hrm#80 which closed
[14]w3c/imsc-hrm#79, and published a release.
[13] https://github.com/w3c/imsc-hrm/issues/80
[14] https://github.com/w3c/imsc-hrm/issues/79
[15]Rec release on GitHub
[15] https://github.com/w3c/imsc-hrm/releases/tag/REC-imsc-hrm-20240425
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 [16]w3c/dapt#216
[16] https://github.com/w3c/dapt/issues/216
github: [17]w3c/dapt#216
[17] https://github.com/w3c/dapt/pull/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 [18]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.
[18] https://github.com/w3c/dapt/pull/216#issuecomment-2072894545
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
[19]Ofcom news article
[19] https://www.ofcom.org.uk/news-centre/2024/ensuring-the-quality-of-tv-and-on-demand-access-services
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
[20]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).
[20] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 25 April 2024 16:17:18 UTC