15:01:22 RRSAgent has joined #tt 15:01:27 logging to https://www.w3.org/2024/04/11-tt-irc 15:01:27 RRSAgent, make logs Public 15:01:28 Meeting: Timed Text Working Group Teleconference 15:01:33 Agenda: https://github.com/w3c/ttwg/issues/279 15:01:40 Previous meeting: https://www.w3.org/2024/03/28-tt-minutes.html 15:01:43 scribe: nigel 15:01:58 Present: Atsushi, Nigel, Pierre 15:02:38 Present+ Gary 15:02:46 Chair: Gary, Nigel 15:02:54 Present+ Matt 15:03:09 Topic: This meeting 15:03:50 Nigel: Today we have IMSC-HRM and a couple of pull requests on DAPT. 15:04:07 .. Anything else for the agenda, or points to make sure we get to? 15:04:19 Present+ Cyril 15:04:50 Cyril: AOB - NAB is coming and we're organising an event we can mention 15:04:53 Nigel: Thank you 15:05:07 Topic: IMSC-HRM 15:05:36 Nigel: The AC Review poll closed, no objections. 15:05:55 .. I think we need a pull request to address the proposed changes? 15:06:37 Atsushi: Yes. I believe we are waiting. Once the pull request is raised and all comments are satisfied 15:07:00 .. we can go to publication. The changes are just suggestions and are all editorial, 15:07:12 .. so it would be possible to go directly to Rec but it would be better to deal with the suggestions and comments. 15:07:35 Nigel: Pierre, are you okay to open a pull request for those? 15:07:49 -> https://github.com/w3c/imsc-hrm/issues/79 A few minor editorial suggestions w3c/imsc-hrm#79 15:08:03 Pierre: I was just waiting to make sure there were no other comments. 15:08:11 .. I will prepare the pull request straight away. 15:08:15 Nigel: Thank you. 15:08:22 .. Anything else to say about this? 15:08:38 nothing more 15:08:45 Topic: DAPT 15:09:16 -> https://github.com/w3c/dapt/labels/agenda Issues labelled "agenda" 15:10:05 Nigel: We discussed these two last time but there were no concrete actions, 15:10:19 .. and we said we would continue the discussion on the pull requests, but we didn't actually do that, 15:10:26 .. so I put them back on the agenda. Hope that's ok! 15:11:26 Subtopic: Replace workflowType with represents w3c/dapt#217 15:11:36 github: https://github.com/w3c/dapt/pull/217 15:12:07 Matt: Apologies, I didn't notice anything coming through to me for the review request. 15:13:08 Nigel: This is about replacing workflowType with represents as a list of the content types that 15:13:11 .. the document represents. 15:13:30 .. Last time we talked we agreed to make the into a Registry Table, 15:13:35 .. and I made that change after the call. 15:14:18 .. We also had it as "alternativeFor" last time and had agreed to change that into "represents" which I also did. 15:15:31 Matt: [recalls the discussion, agrees with the intent] 15:15:49 Nigel: The question for me now is do I go ahead and merge now or wait for a review and 15:15:54 .. take appropriate response on the basis of that. 15:16:01 Matt: I feel I need to read it. 15:16:19 Cyril: I don't have any change to my pull request approval. 15:17:06 .. Just wondering about the granularity of the "represents", could we use represents on Script Events? 15:17:14 Nigel: Further down the tree? 15:17:27 Cyril: Yes, if you want to know which Script Events actually correspond to each type, we already have 15:17:41 .. Script Event Description which is human readable, and we have Script Event Type that has a Registry, 15:17:56 .. but the values don't align - we have dialogue, spoken text, on screen text... 15:19:06 Nigel: Ooh I hadn't thought of that. Looking at it, I agree, it seems like this could be one list. 15:19:51 Matt: I'm happy with the general approach. 15:20:51 Cyril: I'm thinking - if you were to replace the values of represents by the values of Script Event Type... 15:21:08 .. If you made a set of the Script Event Types in the document, would that work? 15:21:36 pal has joined #tt 15:22:13 Nigel: I see 3 options. 15:22:31 .. 1. What you said Cyril, allow the event type values to be coalesced into represents at the document level. 15:23:22 .. 2. Add a mapping from event type into a simpler smaller set of represents values, e.g. title and OnScreenText in event type 15:23:31 .. both map to visualText in represents. 15:24:06 .. 3. Replace eventType with represents and use the same registry table for both. 15:24:24 .. The nuance is that represents allows a list, whereas eventType maybe should be a single value. 15:25:00 Cyril: Sorry I only noticed this now. Also the registry table for script event type needs some descriptions. 15:25:13 .. I like the idea of the column for mapping to represents. 15:25:41 .. I was wondering what the point of spokenText is? 15:25:56 Nigel: We spent no time looking at the registry table values for event type, they're just example values. 15:26:07 Cyril: I agree those are the three options, I don't have a strong view. 15:26:23 .. You may not want the same granularity of description at the document level as at the script event type. 15:26:34 Nigel: That's why I was thinking of the mapping idea. 15:27:16 .. I think that if we want to do the mapping, that would be a new issue and pull request. 15:27:32 Cyril: A 4th option is to not have the document level summary at all but inspect the document contents 15:27:35 .. to see what it contains. 15:27:47 Nigel: That's true, but... 15:28:03 Cyril: In the workflow you want an early indication of the potential uses of the document. 15:28:14 Nigel: So you're arguing against that previous point?! 15:28:26 Cyril: Yes, I just wanted to note the possibility in case we want to come back to this in the future. 15:28:51 Nigel: What to do? 15:28:53 .. Options: 15:29:15 .. 1. Merge now and open a separate issue and pull request to deal with mapping from script event type to represents 15:29:33 .. 2. Go round the loop one more time and try to fix this up before merging 15:29:49 .. 3. Merge now and do nothing about script event type for the time being. 15:30:17 .. By the way we will need to come back to all the Registry Tables at some point to make sue 15:30:27 .. they have the right values. All of the entries are Provisional right now. 15:30:30 s/sue/sure 15:30:45 .. Any preferences? 15:30:54 .. My preference is to merge now and then incrementally improve. 15:31:01 Cyril: We should have an issue that tracks it then. 15:31:28 Nigel: Do you want to open that then? 15:31:35 Cyril: Doing it now. 15:31:56 Matt: Apologies, got to run to another meeting, please prod me if there's any more review needed. Apologies again for not noticing this one. 15:32:02 Matt leaves 15:32:49 SUMMARY: Merge pull request, deal with script event type and represents in a separate issue 15:33:16 Subtopic: Add informative section about mapping from TTML to the DAPT data model w3c/dapt#216 15:33:25 github: https://github.com/w3c/dapt/pull/216 15:35:19 Nigel: From last time, I think the determining factor is if we need a class of DAPT implementation 15:35:34 .. that maps from TTML2 into the DAPT data model. If we do, that means we need to make these 15:35:40 .. provisions normative. 15:35:58 Cyril: Taking a step back, we did this pull request to cover the case that there is a document that 15:36:08 .. conforms to the profile but does not map directly to the DAPT data model. 15:36:28 .. In practice if you have an implementation of DAPT that is "just" DAPT, which I think will be the majority case, 15:36:57 .. then this situation should not happen. You shouldn't end up with a document that cannot be easily mapped. 15:37:03 Nigel: Yes, to a point. 15:37:33 .. The exception could be from the compatibility perspective - some future version of DAPT adds in a feature 15:37:42 .. that we want older DAPT processors to handle gracefully. 15:37:53 .. It's not just about TTML2 generically. 15:37:56 Cyril: You're right. 15:38:28 .. Thinking out loud, if we added constraints like feature extensions to restrict a DAPT document 15:38:41 .. to correspond only to the DAPT data model, what would be the problem? Extensibility? 15:38:47 Nigel: Yes, that would be the main one. 15:39:12 .. It's really the structural issue of divs containing other divs or mixed div and p children. 15:39:23 .. Which we agreed there could be a future use for. 15:39:46 .. If we prohibited that then we wouldn't be able to use that capability in the future without making a 15:39:50 .. breaking version change to DAPT. 15:40:34 .. Maybe we could argue that, to make sure that conformant implementations can deal with those changes, 15:40:42 .. that's why we need to make the informative provisions normative. 15:41:01 Cyril: What about text content anywhere other than p and span? 15:41:13 Nigel: It's allowed in p and span but TTML doesn't allow it anywhere else. 15:41:21 .. Except for metadata elements etc, of course. 15:41:25 Cyril: Ok, thank you. 15:42:38 Nigel: Does that argument about future compat seem correct? 15:42:50 Cyril: Yes. In general I prefer something normative otherwise there won't be interoperability. 15:43:08 .. Does this mean we need a DAPT processor type? 15:43:12 Nigel: No I don't think it does. 15:47:39 Cyril: In §7.2 it defines a DAPT Processor in terms of conformance to the profile provisions and to the document. 15:47:50 .. How would we do that? 15:48:04 Nigel: I'd make extension features referencing the new normative provisions, so it all ties together. 15:48:48 Cyril: I would like to take a stab at re-writing §5 or proposing changes. 15:48:55 Nigel: OK, that's fine, otherwise I'd have done it. 15:49:13 Cyril: Not sure when I'll do it. 15:49:26 Nigel: Why don't I do a first pass, and then you can review it? 15:49:47 Cyril: That's fine. 15:50:09 .. I think we should move the new section 5 to after the Constraints section. We're only concerned 15:50:22 .. with valid documents, which are defined in the Constraints section. 15:50:50 .. I would start by saying that the processing behaviour for a processor processing a valid document that 15:50:59 .. contains additional content not in the DAPT model is the following... 15:51:38 .. Say there may be conformant DAPT docs that contain more, e.g. for a new version, or a round trip through 15:51:41 .. a generic TTML tool. 15:51:50 .. That's how I'd start, by explaining that. 15:52:10 .. Once the context is clear I think it's easier to understand. 15:52:56 Nigel: I think it'll be important to say that the graceful handling feature requirements may be replaced 15:53:39 .. in future versions by something that defines some other behaviour. 15:53:45 Cyril: Did you mention parsing, or just mapping? 15:54:01 Nigel: Just mapping. I think parsing is defined by XML, we're talking about building a data model from the parsed entities. 15:54:04 Cyril: OK 15:54:39 Pierre: Are you going to take the TTML approach of pruning? 15:54:39 Nigel: I don't think so, not quite 15:54:41 Cyril: For validation purposes, yes. 15:54:56 .. But a read/write processor should try to retain unrecognised vocab 15:55:11 Pierre: The reason for mentioning: if the processor sees elements or attributes it does not understand then 15:55:23 .. there's no hope it can understand how to deal with those unknown elements. 15:55:42 .. If you merely preserve them, that doesn't take into account the semantics of the unknown elements. 15:55:57 .. Generally it's not possible unless you specify extension rules such as vocabulary in a particular part of the 15:56:10 .. model does not affect e.g. timing etc. 15:56:41 .. Some things can be preserved with minimal risk, but everything else, it's hopeless. 15:57:03 Cyril: You can have multiple values of profiles in the contentProfiles attribute, but if you write back 15:57:17 .. a file then you shouldn't write back values of contentProfiles that you don't understand. 15:57:52 .. You could end up with semantically incorrect content. 15:58:14 Nigel: Example is an attribute for number of words, doc says 3, editor adds 2, saves the value as 3 because it 15:58:17 .. doesn't understand it. 15:58:31 Pierre: There's a danger of getting rules that are so complex that nobody understands them. 15:58:58 Pierre: The TTML model is blunt but straightforward. Just get rid of everything you don't understand. 15:59:10 .. Maybe some stuff could have been kept, but at least it is predictable. 15:59:20 .. When the author wants the document to be compatible with an older version, 15:59:32 .. do it so that when you strip the newer stuff it's still valid for the older version. 16:00:05 SUMMARY: @nigelmegitt to make edits as discussed, @cconcolato to review, discussion to continue. 16:00:48 Topic: AOB 16:01:12 Cyril: there's an event happening where we're gauging appetite to talk about live captioning, 16:01:25 .. wondering if there's a TTWG view on it. It's on Monday. 16:02:12 Nigel: I don't think I can say anything about this as a Chair because we've not really discussed it in TTWG. 16:02:26 .. But I may be able to say something in my BBC role. 16:02:36 .. Can we take this offline please? 16:03:18 Cyril: Can we add this as an AOB for after the meeting so we can summarise the outcomes? 16:03:21 Nigel: Sounds like a good idea. 16:03:26 Topic: Meeting close 16:03:43 Nigel: We're 3 minutes over, thanks everyone! [adjourns meeting] 16:03:55 rrsagent, make minutes 16:03:56 I have made the request to generate https://www.w3.org/2024/04/11-tt-minutes.html nigel 16:08:26 scribeOptions: -final -noEmbedDiagnostics 16:08:30 zakim, end meeting 16:08:30 As of this point the attendees have been Atsushi, Nigel, Pierre, Gary, Matt, Cyril 16:08:32 RRSAgent, please draft minutes v2 16:08:33 I have made the request to generate https://www.w3.org/2024/04/11-tt-minutes.html Zakim 16:08:39 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 16:08:40 Zakim has left #tt 16:16:08 rrsagent, excuse us 16:16:08 I see no action items