15:57:49 RRSAgent has joined #tt 15:57:53 logging to https://www.w3.org/2024/03/28-tt-irc 15:57:53 RRSAgent, make logs Public 15:57:54 Meeting: Timed Text Working Group Teleconference 15:58:03 Agenda: https://github.com/w3c/ttwg/issues/278 15:58:10 Previous meeting: https://www.w3.org/2024/03/14-tt-minutes.html 15:58:13 scribe: nigel 15:58:17 Present: Nigel 15:58:29 rrsagent, make minutes 15:58:30 I have made the request to generate https://www.w3.org/2024/03/28-tt-minutes.html nigel 15:58:44 Present+ Andreas 16:02:02 Present+ Pierre, Cyril 16:03:47 Topic: This meeting 16:03:58 Nigel: Today we have IMSC-HRM AC Review of PR, 16:04:04 .. and DAPT issues and pull requests. 16:04:15 .. Any other business, or points to make sure we get to? 16:04:23 Present+ Gary 16:04:29 Chair: Gary, Nigel 16:04:40 no other business 16:04:53 Topic: IMSC-HRM AC Review of PR 16:05:15 -> Poll results https://www.w3.org/2002/09/wbs/33280/202402-PR-IMSC-HRM/results 16:05:38 Nigel: [summarises results] 16:05:42 .. The poll closes today 16:06:17 .. I think there have been some attempts to get more responses, from various people, 16:06:20 .. so thank you for that. 16:07:37 .. From what I can see, it appears to be a formality to move to Rec from this, as it stands. 16:07:51 .. Obviously we don't have Atsushi to speak for the team. 16:08:04 Regrets: Atsushi 16:08:09 atai has joined #tt 16:13:45 Topic: DAPT 16:14:03 Nigel: I've been busy since last call, and we should take a look. 16:14:21 -> https://github.com/w3c/dapt/labels/agenda DAPT issues labelled for agenda 16:14:57 Subtopic: Changing workflowType to alternativeFor 16:15:13 github: https://github.com/w3c/dapt/pull/217 16:15:26 -> https://github.com/w3c/dapt/pull/217 Replace workflowType with alternativeFor w3c/dapt#217 16:15:34 Nigel: Related issue: 16:16:00 -> https://github.com/w3c/dapt/issues/169 Support within workflowType for generic script origination w3c/dapt#169 16:16:41 Nigel: The problem we had was that workflowType, being restricted to audioDescription or dubbing, 16:16:50 .. didn't actually work all that well for everyone in the chain. 16:17:03 .. For example it didn't cover things like production of a transcript and/or translation 16:17:10 .. with the intent of using it for subtitles. 16:17:49 Cyril has joined #tt 16:18:00 .. So I replaced it with alternativeFor, which is a description of which components of the related media 16:18:13 .. the document contents represent, or are an alternative for. 16:18:33 .. It's a comma separated list, with four possible values in the list. 16:18:48 .. Those are dialogue, nonDialogueSounds, visualNonText and visualText. 16:19:01 .. Very few other changes were needed. 16:19:17 .. Two questions from me: 16:19:29 RRSAgent, pointer 16:19:29 See https://www.w3.org/2024/03/28-tt-irc#T16-19-29 16:19:32 .. 1. Since nothing depends on this list, at present, should the values come from a Registry Table 16:19:46 .. 2. Should we keep this as a mandatory attribute, or can it be optional? 16:19:50 s/Table/Table? 16:20:06 q+ 16:20:16 Cyril: I don't disagree with how it's done. 16:20:30 .. Wondering if the term "alternativeFor" is the right term. I think we had "represents" before. 16:20:38 .. Why this choice? 16:20:53 Nigel: Yes, I thought someone didn't like "represents", maybe you Cyril?! 16:21:09 .. Also, I wanted to tie it in with accessibility language and terminology a bit more closely, 16:21:21 .. so that people in that world are comfortable with what this is doing. 16:21:50 .. I don't mind changing it to a different name. 16:22:10 ack atai 16:22:24 Andreas: When I read the term, I was wondering what it means too - it's not intuitive. 16:22:35 .. If we go in this direction, "represents" as a term is more accessible. 16:22:57 .. Also, in the approach, I see the benefit of it, and the goal to separate the different uses more clearly. 16:23:11 .. But it kind of breaks with terms used in the industry like dubbing and audio description. 16:23:25 .. For that, they need to get their head around it. That's my first impression. 16:23:43 Nigel: I did add a note about typical values for those use cases but I get what you mean. 16:24:07 Cyril: As you indicated, "alternative" is a key word for accessibility. I need to think about it. 16:24:42 .. I'm not sure a transcript is really an alternative - is the transcript used to produce dubbing or AD really an alternative? 16:25:03 Nigel: I'm not glued to this - I've explained my reasoning, but the reasons aren't strong. 16:25:18 Cyril: Regarding the question about registry, I'm not sure. 16:25:31 .. It's good for implementation and extensibility to use a registry. 16:25:47 .. But the way you've structured the keywords, it feels like it covers the entire space, 16:26:05 .. with the union representing everything. 16:26:21 Nigel: Maybe, but there could be something else. 16:26:35 Cyril: You might want more granularity - text could be signs, time and dates etc. 16:26:42 .. So now I think about it, using a registry is better probably. 16:26:46 Nigel: OK 16:26:59 Cyril: The last question was about making it optional vs mandatory. 16:27:11 .. What is the use case where you wouldn't know what your script represents? 16:27:25 .. It may evolve, but at any point in time you should know what the script represents. 16:27:31 .. so I still think it should be mandatory. 16:28:29 Nigel: I'm happy to take the action to turn the content-descriptor values into a Registry Table. 16:28:47 .. The other possible action is renaming it to "represents" or some other thing. 16:29:59 Cyril: [reads the original issue] I don't think I have a problem with "represents" 16:30:09 Nigel: OK, any other thoughts before I give myself the action to change it? 16:30:14 no other comments 16:30:48 SUMMARY: @nigelmegitt Change `` to be a Registry Table; change name to "represents". 16:31:20 Subtopic: Add informative section about mapping from TTML to the DAPT data model w3c/dapt#216 16:31:27 github: https://github.com/w3c/dapt/pull/216 16:32:13 Nigel: Quite a big change, new informative section added, mostly as discussed in the issue and our previous call. 16:32:45 .. Introduces some implementation considerations for ingesting generic TTML2 documents that are also 16:32:58 .. DAPT conformant, which might not have a 1:1 mapping to the DAPT Data Model. 16:33:25 .. My biggest question is: is there anything in here that anyone thinks needs to be normative? 16:33:32 q+ 16:33:35 Cyril: Thank you for this, I started to review it, and that was my biggest question. 16:33:52 .. You phrased it that there is no requirement for DAPT implementations to perform the task... 16:34:05 .. which is what? Parsing the DAPT document into a DAPT Data Model? 16:34:58 Nigel: It's "attempting to populate a data structure corresponding to the DAPT data model from any conformant DAPT document" 16:35:56 Cyril: Why isn't that a requirement? 16:36:42 Nigel: Because the only normative requirement is that a processor conforming to the TTML2 profile can process 16:36:45 .. the document. 16:37:00 Andreas: But a DAPT processor should be able to do it? 16:37:08 Nigel: That's not a thing though, a "DAPT processor" 16:37:26 Andreas: You ask if there's any concern about making this informative, and I think I mentioned in the last 16:37:35 .. call that I have some questions about whether that's enough. 16:37:48 .. My simple thinking: 2 implementations that implement DAPT, are DAPT implementations. 16:38:02 .. If they're parsing DAPT-conformant TTML documents they should have the same result, 16:38:14 .. so that there's interoperability. If you leave this open to be implementation dependent, 16:38:24 .. that could be a problem. Could they come up with different results? 16:38:27 q+ 16:38:32 ack atai 16:38:43 .. This would be my main question when I come to review it. 16:38:46 ack n 16:39:13 Nigel: The reason I don't think that's a problem is because the semantics for processing the document 16:39:18 .. are normatively defined by TTML2. 16:39:53 .. Where we might need something normative would be if we wanted to have a fixed mapping back from 16:40:09 .. every possible DAPT conformant document into the DAPT data model. 16:40:32 .. Because that data model is defined by this spec, there can't be normative requirements for doing that within TTML. 16:40:34 q+ 16:40:59 Andreas: Again, maybe it's simple how I'm thinking, but a possible implementation would be to make the DAPT 16:41:13 .. data model the internal data model, and handle the document accordingly. 16:41:15 ack at 16:41:19 q+ 16:41:26 .. If two implementations do this I would assume they come up with the same values. 16:41:29 ack cy 16:41:48 Cyril: I'm wondering what are the classes of TTML processor that could do something meaningful with 16:42:04 .. a DAPT document. For example if I have a TTML authoring tool and I load a DAPT document, 16:42:18 .. I don't think the generic tool would be able to do any edits and guarantee that the output would 16:42:33 .. remain conformant with the profile. Are you thinking that a generic authoring tool would see what is 16:42:46 .. permitted or prohibited and constrain its UI to do only what's permitted? 16:43:00 .. The bigger question: yes, a DAPT document is a TTML document, but is that useful for having a TTML 16:43:11 .. processor process the document. I think we need tailored DAPT processors. 16:43:18 .. They will do meaningful edits to the document. 16:43:36 .. Just knowing they are TTML documents does not seem to be sufficient to do meaningful edits. 16:43:40 q? 16:44:03 Nigel: A generic TTML2 presentation processor that supports audio features should be able to 16:44:13 .. play back a DAPT audio description script for example. 16:44:34 .. A generic TTML2 transformation processor can observe the profile feature and extension requirements 16:44:56 .. and decide if it supports the required features or not, and if it doesn't, presumably all bets are off, in terms of 16:44:58 .. what it does. 16:45:13 .. My thinking is that the profile constraints manage this for us. 16:45:19 Cyril: On the playback side, I agree. 16:45:39 .. A generic TTML processor could present a DAPT document without knowing about the DAPT data model, for sure. 16:45:59 .. For a generic TTML transformation processor, that seems like a theoretical concept, so I wouldn't worry about these. 16:46:21 .. So I think we should introduce a DAPT processor, which does not necessarily support generic TTML processing, 16:46:32 .. but does support DAPT Data model processing. 16:46:47 .. Then that section that you wrote can have SHALL statements that only apply to this class of processor. 16:47:15 Nigel: This is for validators, or editors? 16:47:42 .. I have another concern, which is extensibility of DAPT, and forwards/backwards compatibility. 16:48:23 .. If we do as you suggest Cyril, how do we avoid introducing compatibility issues in the future? 16:48:32 Cyril: Can you repeat the example? 16:48:53 Nigel: If we introduce a new entity into the data model in the future, for example. E.g. a Script Event grouping 16:49:07 .. structure. Wouldn't that break this new class of DAPT processor? 16:49:33 Cyril: Generically, if we define a new entity that does not exist today at all, the old data model processors 16:49:56 .. would ignore it, but the grouping one is a special case - I think that's what you've done, to identify 16:50:03 .. what is a script event wherever it is in the document. 16:51:10 Nigel: I think the answer will hinge on whether we really need a DAPT processor class. 16:51:17 .. It would be helpful to get review comments on the pull request. 16:51:39 Cyril: When I looked at your example, today we seem to rely on the xml:id to decide if a div might be a 16:51:58 .. Script Event. I wonder if we should have a ttm:role that says "script event" more explicitly. 16:52:06 .. Then the DAPT processor just finds this, and that's it. 16:52:16 .. How deeply nested in the TTML shouldn't matter. 16:52:19 .. Other things can be pruned. 16:52:37 .. You do whatever you want with the rest. That seems simpler to me. 16:53:23 Nigel: If we do that then we need structural constraints, that we currently don't list. 16:53:49 .. For example what if a div marked as a Script Event contains another div marked as a Script Event. 16:53:59 Cyril: Yes, we could have constraints about that. 16:54:09 Nigel: Yes, that's an option. 16:55:09 .. My overall direction here is steered by "less is more", and if we don't need a DAPT Processor, say, 16:55:37 .. then we shouldn't create one. Of course maybe it is actually important, and we should define it. 16:55:58 Cyril: The original question is what a processor should do if it encounters a DAPT document with 16:56:13 .. contents that go beyond what would get directly made by a mapping from this version's DAPT Data Model. 16:56:16 Nigel: Yes. 16:57:23 SUMMARY: Reviews to continue, revisit this after more thought and discussion. 16:57:28 Subtopic: Other Pull requests 16:57:46 Nigel: I opened two more pull requests, one to add at-risk features, the other to 16:58:01 .. define empty Text and note the use case for omitting Text objects. 16:58:11 .. I see they've recently been approved - thank you! 16:58:31 Topic: Next meeting - time will be adjusted 16:58:52 Nigel: Next meeting, and going forwards until next DST switch, the UTC time of the call will be adjusted 16:59:16 .. to be an hour earlier, as previously discussed. Back to the "usual" local time, except in places without DST. 16:59:51 Topic: Meeting close 17:00:05 Nigel: Thanks everyone, we're just about at time. [adjourns meeting] 17:00:09 rrsagent, make minutes 17:00:10 I have made the request to generate https://www.w3.org/2024/03/28-tt-minutes.html nigel 17:05:03 scribeOptions: -final -noEmbedDiagnostics 17:05:10 zakim, end meeting 17:05:10 As of this point the attendees have been Nigel, Andreas, Pierre, Cyril, Gary 17:05:12 RRSAgent, please draft minutes v2 17:05:13 I have made the request to generate https://www.w3.org/2024/03/28-tt-minutes.html Zakim 17:05:19 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 17:05:19 Zakim has left #tt 17:05:37 rrsagent, excuse us 17:05:37 I see no action items