14:58:32 RRSAgent has joined #tt 14:58:37 logging to https://www.w3.org/2024/04/25-tt-irc 14:58:37 RRSAgent, make logs Public 14:58:38 Meeting: Timed Text Working Group Teleconference 14:58:42 Agenda: https://github.com/w3c/ttwg/issues/280 14:58:53 Previous meeting: https://www.w3.org/2024/04/11-tt-minutes.html 14:59:08 present: Nigel 14:59:17 Chair: Nigel 14:59:24 rrsagent, make minutes 14:59:25 I have made the request to generate https://www.w3.org/2024/04/25-tt-minutes.html nigel 14:59:57 Regrets: Gary, Chris_Needham 15:00:22 scribe: nigel 15:01:44 Present+ Pierre, Matt 15:02:34 Topic: This meeting 15:03:39 Present+ Cyril 15:04:04 Nigel: Today's agenda: 15:04:10 .. * IMSC-HRM Rec publication 15:04:21 MattS has joined #tt 15:04:31 .. * DAPT agenda items 15:04:40 .. * AOB from Cyril about the recent live captioning industry event 15:05:04 .. * AOB from Nigel about the UK regulator Ofcom's updated Access Services Best Practice Guidelines 15:05:10 .. Anything else for the agenda? 15:05:23 group: nothing else 15:05:29 Topic: IMSC-HRM 15:05:53 Nigel: Great news - as you'll have seen on emails, we published the Recommendation today. 15:06:27 -> https://www.w3.org/TR/2024/REC-imsc-hrm-20240425/ IMSC-HRM Rec 2024-04-25 15:06:44 .. Big thank you to everyone for contributing to this, 15:06:50 .. and special shout out to Pierre for Editing. 15:07:25 Pierre: Thanks to Movielabs for supporting me in this. 15:07:35 .. I plan to publicise this early next week, let me know if you want to join in. 15:07:40 Present+ Atsushi 15:07:54 .. My experience when testing it is it's really useful for making sure that one's library 15:08:08 atai has joined #tt 15:08:08 .. does not contain subtitle files with errors or that are too complex. 15:08:12 Atsushi: Congratulations. 15:08:21 s/x./x. Thanks everybody. 15:08:32 Pierre: I'd like to note that at the end we had two implementations! 15:08:43 .. Thanks Nigel, I think that was good, we found a bunch of bugs. 15:09:02 Nigel: It really validated the usual approach of having more than one implementation, that experience. 15:09:53 .. Pierre, I saw you merged w3c/imsc-hrm#80 which closed w3c/imsc-hrm#79, and published a release. 15:10:19 -> https://github.com/w3c/imsc-hrm/releases/tag/REC-imsc-hrm-20240425 Rec release on GitHub 15:10:38 Nigel: Thank you for that. This concludes the work on this specification for the time being. 15:10:40 Pierre: Indeed. 15:10:50 Nigel: Which raises the question: what next? 15:11:17 .. When we began this refactoring process we said we wanted to remove the HRM text from the IMSC specifications. 15:11:44 .. That's the next question - do we go ahead and do that change on its own, or wait until there are other 15:11:52 .. substantive changes to make and then go ahead and do it together? 15:11:57 Pierre: My preference is to wait. 15:12:40 Nigel: That's fine for me - one thing that would change the picture would be if someone came to us 15:13:03 .. and said they wanted to reference IMSC-HRM separately in their requirements. 15:13:19 Pierre: Yes, that would fall into the category of any "can't live with it" issue in IMSC. 15:13:31 .. I will open an issue on IMSC to factor out the HRM so that we don't forget it. 15:14:24 Nigel: Anything else to raise about IMSC-HRM? 15:14:45 No other matters 15:14:50 Topic: DAPT 15:15:26 Nigel: We have one item on the agenda, but I also want to raise another point about ttm:role 15:15:54 Subtopic: Add informative section about mapping from TTML to the DAPT data model w3c/dapt#216 15:16:09 github: https://github.com/w3c/dapt/pull/216 15:16:23 Nigel: We discussed this last call and I began working on the edits to the pull request, 15:16:41 .. but then realised we hadn't concluded properly on something where two mutually exclusive views 15:16:45 .. had been presented. 15:18:43 Nigel: [summarises https://github.com/w3c/dapt/pull/216#issuecomment-2072894545] 15:19:07 .. From the Cyril's response I think it's clear that for vocabulary in DAPT or TTML namespaces, or any 15:19:29 .. namespace included in the spec, processors should not write out vocabulary relating to features they don't support. 15:19:47 .. My next question is: what about stuff in completely different namespaces? 15:20:06 .. Like locally defined metadata. 15:20:30 Pierre: Unless the spec defines a place in the model for metadata, with enough semantics that 15:20:44 .. the processor can do something with it without knowing its contents, the safest thing is for the processor 15:20:49 .. to prune them altogether. 15:21:08 Nigel: Such a place might be as a child of the element for example. 15:21:53 Pierre: You might say that in head/metadata, temporally, any metadata applies to the whole document. 15:22:08 .. They might still put in some average word count, say, so a processor that doesn't know it could 15:22:24 .. update the document and invalidate it. 15:22:29 q+ cyril 15:23:38 q+ 15:23:43 .. From a spec perspective it makes sense to prune all unknown vocabulary. It's the best approach. 15:23:47 ack cyril 15:24:00 Cyril: A few points. I may have responded too quickly! I'm thinking about changing my mind. 15:24:24 .. With an MP4 file, if there are boxes I don't understand, do I expect a processor to remove them? 15:24:34 .. You would remove the declaration of the features not understood. 15:24:44 .. In TTML, you would definitely remove the contentProfiles that aren't supported. 15:24:50 .. Does it mean you have to remove everything? 15:25:08 .. You could remove it, but if you leave it in, then you're not claiming its validity. 15:25:22 .. The entity that would process the document could decide to keep, say, a word count element, 15:25:27 .. but would remove the contentProfiles declaration. 15:25:48 .. Secondly, when you rewrite a document, it's two steps: parsing and then writing. 15:26:07 .. What's the difference here? You could write valid documents against the specifications you declare validity for. 15:26:24 .. Option 1 was "MUST omit" - I think it is probably too strong. 15:26:34 q+ 15:27:00 ack ata 15:27:25 Andreas: I'm a bit reluctant if we recommend at all to prune unknown vocabulary especially in foreign namespaces, 15:27:38 .. because it could remove some benefits of extending TTML documents with data, especially metadata. 15:27:51 .. From the user point of view, what could you expect if foreign namespace metadata is in the document, 15:28:02 .. and it goes through an implementation not controlled by the user. 15:28:17 .. You could say it is implementation dependent, but in the best case it stays where it was before. 15:28:28 .. Then the user needs to live with the fact that it may not be meaningful any more. 15:28:54 .. If we recommend pruning, then metadata would only survive implementations that understand it. 15:28:59 .. I think that's too strong a requirement. 15:29:19 Pierre: Just to clarify, I'm saying this strictly from a specification conformance perspective. 15:29:28 .. I expect implementations to do whatever. 15:29:51 Cyril: What does it mean though, because if the implementation doesn't meet the spec then it's not compliant. 15:30:10 Pierre: Say there's a presentation processor, pruning unknown vocabulary can be tested. 15:30:26 .. If you feed a presentation processor two documents, one with foreign vocab and one without, you 15:30:30 .. would expect the same outcome. 15:30:43 .. If there is a conformance for a translation or transport processor... 15:30:49 Nigel: That's what we're talking about 15:31:07 Pierre: From my experience in TTML and MXF, I've only seen pain in trying to keep around things that 15:31:12 .. you don't know what they are. 15:31:21 .. From a conformance standpoint it's either a MUST or nothing. 15:31:35 q? 15:31:35 ack nigel 15:31:46 Nigel: The point about contentProfiles was agreed, there was no doubt about that. 15:32:07 .. We are talking about a document that reads and writes DAPT documents, rather than a presentation processor. 15:32:27 .. A suggestion I have based on the above is as follows: 15:35:10 .. If there is any feature or vocabulary that has some semantic that means it could be invalidated by being 15:35:38 .. "passed through" then the definer of that vocabulary better make a profile for it and have that appear in 15:35:49 .. contentProfiles when output by a processor that supports it. 15:36:09 .. Other vocabulary that is just inside any metadata element can be passed through and no assumptions 15:36:14 .. about validity should be made. 15:36:37 .. I think we should prune any unsupported vocabulary in namespaces listed in DAPT though. 15:37:04 .. The third part is that a processor that does support some extra profile and receives a document that 15:37:25 .. doesn't claim conformance to that profile but does contain vocabulary relating to it needs to take extra 15:37:32 .. validation steps and may need to modify it. 15:37:48 .. That last point is hard to write a testable specification conformance rule for. 15:37:54 Cyril has joined #tt 15:38:04 RRSAgent, pointer 15:38:04 See https://www.w3.org/2024/04/25-tt-irc#T15-38-04 15:38:16 Nigel: Does that make any sense? 15:38:42 pal has joined #tt 15:38:53 q+ 15:39:37 Cyril: What can we say about the definer of vocabulary making a profile? 15:39:45 Nigel: We can make a note recommending that people do this. 15:39:47 Cyril: That's fine. 15:40:02 Andreas: I think at least the first two options seem fine to me, but they're more recommendations 15:40:09 .. to the author than the processor, right? 15:40:34 Nigel: From this I can define processor behaviour, as follows: 15:40:58 .. 1. Never include in ttp:contentProfile profiles which the processor does not support. 15:41:27 .. 2. Foreign namespace vocabulary in elements should be preserved 15:41:51 .. 3. Non-foreign namespace vocabulary that is not supported MUST be removed 15:42:18 .. And then there's advice too, for authors as you suggest. 15:42:24 q+ 15:42:32 ack at 15:42:44 Andreas: Yes I think those are processor requirements. 15:42:55 Pierre: Number 2 is not testable because of the SHOULD. 15:43:11 q+ 15:43:16 .. By the way, I think that's what will happen in practice, but from a spec perspective it is not testable. 15:43:17 q- 15:43:23 ack at 15:43:39 Andreas: I think that it's implementation dependent, what happens, but whatever keyword you use 15:43:51 .. it is a recommendation to keep where possible. In some cases it may not be possible, 15:44:07 .. because a semantically identical document has its structure changed, and the parent of the metadata element 15:44:14 .. was removed while doing that. 15:44:40 Nigel: That last point is a whole other headache - I think with DAPT it should not happen but I guess it is possible. 15:45:23 Pierre: The only alternative I can think of is to preserve vocabulary but if you put it in a particular 15:45:35 .. location then it has limited impact. It's going to be fragile I think. 15:45:54 Nigel: There's a good test case there for us to think about which is what if you take a DAPT document 15:46:03 .. and add styling in to make it an IMSC document. 15:46:13 Cyril: I was thinking the same thing. 15:46:38 .. I'm wondering if, once you start making a subtitle out of a DAPT document, you've forked it and you're 15:46:49 .. in the subtitling space - I'm not sure you'd want to go back to the DAPT processor for anything. 15:46:54 .. It's a one-way door I would say. 15:47:23 Pierre: One thing just occurred: does the spec really need to define a transformation processor? 15:47:34 Nigel: Validation processors are a subset of transformation processors. 15:47:43 Pierre: Just for validation it's okay to prune everything that's unknown. 15:48:10 .. Maybe just don't define transformation processor other than validation processor so we don't need this? 15:48:23 Nigel: That's where I started out when we began thinking about this. 15:48:28 q? 15:49:16 Nigel: I think I have enough to go ahead and try editing here, and see how that works out. 15:49:59 SUMMARY: @nigelmegitt to attempt to edit this into the pull request; everyone else to think about the semantics for including TTML styling vocabulary. 15:50:25 Topic: AOB - Captioning industry event 15:50:43 Cyril: Three of us, Pierre, myself and Andreas were there. 15:50:51 .. There will be a report posted soon, summarising what happened. 15:51:05 .. The gist of it is that it was a very successful event, with a lot of people attending 15:51:20 .. from various parts of the industry, from studios to caption vendors to universities - very broad. 15:51:33 .. There will be follow-ups I think, possibly in Europe so others can have a chance to attend. 15:51:51 .. The outcome is probably that at least for live streaming the technologies we have in place are not 15:52:06 .. sufficient to address a global market, Asia, Europe, US. 15:52:19 .. It's probably not a lack of standards, more a lack of guidelines and good practices. 15:52:30 .. There was a strong support for TTML in the room, people saying TTML could solve all of it. 15:52:36 .. That's my quick summary. 15:52:51 Pierre: I'm about to start writing the report so I'll withhold my final opinion! 15:53:04 .. Something that struck me was an intense desire in the room to do more interop testing. 15:53:22 .. From a high level user/ecosystem standpoint there's a perception that there isn't enough interop testing being done. 15:53:34 .. What's fed at one end of the chain comes out very different at the other end. 15:53:54 .. The strongest immediate desire in the room, among other things, was to make progress with interop. 15:54:14 Andreas: One main outcome was everyone was interested in following up and keeping the community, 15:54:25 .. finding a forum to collaborate and work on these issues. 15:54:41 Cyril: Maybe for another time, we should think about how this working group can get more feedback 15:54:44 .. on its activities. 15:55:04 Pierre: Thinking out loud, many folk who attended would never attend TTWG because it's down in the details 15:55:18 .. for them - that's a good thing! There might need to be a higher level forum where operational and practical 15:55:35 .. issues are discussed. I think there was agreement that the core standards exist, but it's how to use them 15:55:39 .. that generated the friction. 15:55:57 .. Ultimately how the industry works with this group is super important I think. 15:56:11 Nigel: Thank you for the great summary, and for telling us about this. 15:56:47 Topic: AOB - UK regulator Ofcom's recent updates 15:57:25 -> https://www.ofcom.org.uk/news-centre/2024/ensuring-the-quality-of-tv-and-on-demand-access-services Ofcom news article 15:57:47 Nigel: Quick AOB - the UK regulator Ofcom updated its Access Services Code (the requirements) and 15:57:57 .. the associated Best Practice Guidelines. 15:58:19 .. The goal of the work I think is to pave the way for UK regulation of the accessibility of video media, whether 15:58:22 .. on broadcast or online. 15:58:48 .. There's a UK government bill in progress which will bring big streamers into regulatory control, for example, 15:58:53 .. and Ofcom will have to do that. 16:00:26 Nigel: If the UK's approach is of interest, it's worth checking out that page and following the links. 16:00:44 Topic: Meeting close 16:00:55 Nigel: Thanks everyone, next meeting in 2 weeks as usual. [adjourns meeting] 16:01:13 rrsagent, make minutes 16:01:14 I have made the request to generate https://www.w3.org/2024/04/25-tt-minutes.html nigel 16:03:02 s/fall into the category of any/fall into the same category as any 16:07:13 s/5]/5 ] 16:07:28 s/From the Cyril/From Cyril 16:13:34 rrsagent, make minutes 16:13:36 I have made the request to generate https://www.w3.org/2024/04/25-tt-minutes.html nigel 16:13:53 Present+ Andreas 16:13:54 rrsagent, make minutes 16:13:55 I have made the request to generate https://www.w3.org/2024/04/25-tt-minutes.html nigel 16:14:57 scribeOptions: -final -noEmbedDiagnostics 16:15:01 zakim, end meeting 16:15:01 As of this point the attendees have been Nigel, Pierre, Matt, Cyril, Atsushi, Andreas 16:15:03 RRSAgent, please draft minutes v2 16:15:04 I have made the request to generate https://www.w3.org/2024/04/25-tt-minutes.html Zakim 16:15:10 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:15:11 Zakim has left #tt 16:15:21 rrsagent, excuse us 16:15:21 I see no action items