15:57:39 RRSAgent has joined #tt 15:57:43 logging to https://www.w3.org/2022/12/22-tt-irc 15:57:43 RRSAgent, make logs Public 15:57:44 Meeting: Timed Text Working Group Teleconference 15:57:46 Agenda: https://github.com/w3c/ttwg/issues/235 15:57:56 Previous meeting: https://www.w3.org/2022/12/08-tt-minutes.html 15:58:01 Present+ Nigel 15:58:08 scribe: nigel 15:58:29 Regrets: none 16:00:19 Present+ Pierre 16:01:21 Present+ Gary 16:01:25 Chair: Gary, Nigel 16:01:46 Present+ Atsushi 16:02:32 atsushi has joined #tt 16:03:58 Topic: This Meeting 16:04:50 Nigel: Today we have: 16:05:04 .. * Rechartering Formal Objection Council status update 16:05:14 .. * DAPT 16:05:17 .. * IMSC-HRM 16:05:31 .. * AOB - 1st meeting of next year. 16:05:40 .. Any other AOB? 16:05:54 Topic: Rechartering Formal Objection Council status update 16:06:27 Nigel: Thanks Atsushi for pointing me at messages that PLH sent recently: 16:06:38 -> https://lists.w3.org/Archives/Member/member-charters-review/2022Dec/0001.html 16:06:44 -> https://lists.w3.org/Archives/Member/member-charters-review/2022Dec/0000.html 16:09:40 Nigel: This is partly in response to the Members' meeting at 1400 on 2022-12-20 and the conversation 16:09:53 .. that I, Philippe, and Florian had about the options for FO Council. 16:10:15 .. However, it does mean that the frustration with getting a timely response may return if they do not 16:10:29 .. answer quickly. In the meantime, what is going to happen about the TTWG Charter that expires 16:10:33 .. at the end of the year? 16:11:10 Atsushi: As far as I heard, FO Council may not provide decision, but provided proposal that TTWG accepted. 16:11:33 .. So if the counter-parties accept that then that would resolve the objections, which might be one possible scenario for now. 16:11:58 Nigel: Yes. My question is what will happen to the TTWG Charter? 16:12:12 Atsushi: In parallel, a short extension is expected, from my conversation with Philippe. 16:12:20 Nigel: Okay, thank you. 16:12:54 Atsushi: At least with that, possible publications around Jan/Feb. 16:14:52 Nigel: Any more points to raise on this topic? 16:15:11 Topic: IMSC-HRM 16:16:16 Subtopic: CR1 Exit Criteria 16:16:21 github: https://github.com/w3c/imsc-hrm/pull/59 16:17:14 Nigel: Is this still a draft PR? 16:17:22 Pierre: Yes, to prevent merging, as much as anything else. 16:17:31 .. The outstanding thing is how to label at-risk features. 16:17:36 .. I'm not happy with it. 16:17:48 .. I think we should go back to a simple statement rather than linking to issues. 16:18:03 .. It's confusing, and doesn't bring us anything because we don't have many features at risk. 16:18:15 q+ 16:18:23 .. I propose to remove those links. 16:18:26 ack nb 16:18:27 ack n 16:18:44 Nigel: I'm not sure what the problem is - I'm actually quite happy with it as it stands. 16:19:17 Pierre: OK, what about you Atsushi? 16:19:29 Atsushi: I don't have objections 16:19:38 Pierre: Okay, maybe we should resolve those threads and call it done. 16:19:49 SUMMARY: Proceed as-is 16:20:12 Subtopic: Clarify that the IMSC HRM specifies document conformance w3c/imsc-hrm#60 16:20:17 https://github.com/w3c/imsc-hrm/pull/60 : Clarify that the IMSC HRM specifies document conformance 16:20:29 Github: https://github.com/w3c/imsc-hrm/pull/60 16:20:45 Pierre: Mostly a discussion between me and Nigel. 16:20:57 .. I'm proposing that conformance be expressed in terms of a sequence of ISDs 16:21:03 .. generated from a collection of IMSC Documents. 16:21:14 .. My thinking is that there is an unambiguous procedure for doing that so 16:21:26 .. I think it's pretty clear. I'm not sure I fully understand your concerns Nigel. 16:21:41 .. I understand one practical concern, that the test suite is not going to have a sequence of ISDs 16:21:46 .. as artefacts, that I agree with. 16:21:58 .. In my mind the conformance section of the document is very different from the testing artefacts 16:22:14 .. and what's in the spec can be more abstract than what is in the tests so I don't see the conflict there. 16:22:19 q+ 16:22:53 .. I want to understand what you see as the issue with conformance being of a sequence of ISDs 16:23:02 .. generated from a group of IMSC Documents. 16:23:04 ack ni 16:23:27 Nigel: I completely agree with how you just expressed it but that's not what the spec says. 16:25:37 .. It doesn't say that the sequence of ISDs are from an IMSC Document. 16:26:03 Pierre: I think you're concerned with the turn of the sentence that starts "Given a sequence of ISDs ..." 16:26:08 Nigel: Yes I think that's right 16:26:20 Pierre: Okay, thanks, I'll propose a change to the sentence to flip that round. 16:26:48 .. It's important to leave it loose because "given a sequence of IMSC documents" the sequence of ISDs 16:27:07 .. is not the same as what you process. First, the last ISD is infinite. Second, there's typically some 16:27:14 .. temporal interval used to clip the sequence. 16:27:30 .. I don't think we need to go to that detail in the conformance, I think we need to keep it vague. 16:27:47 Nigel: Two things. Infinite last ISD, and application of temporal clipping. 16:28:22 .. Looking at Infinite last ISD, I don't think that makes any difference, because there's no work to do 16:28:41 .. on the last ISD. 16:28:54 Pierre: Unless there's a sequence of IMSC documents and you need to move on to the next one 16:28:59 .. before the ISD from the current one ends. 16:29:21 Nigel: Ah, that's another issue again, about sequence handling which I don't think we've formally defined. 16:29:34 Pierre: That's because the algorithm doesn't care - it just cares about ISDs, which is so that we don't have 16:29:44 .. to deal with clipping of ISDs etc. 16:32:00 Nigel: Let's say there's an error found in an ISD that's clipped at the boundary of two IMSC documents. 16:32:10 .. Is it the first doc, the second doc, or the clipping metadata? 16:32:50 .. We have no control or knowledge of the clipping metadata, but we need to declare what thing is non-conformant. 16:33:22 Pierre: Is your concern that it will be difficult in testing to separate ISD creation from IMSC HRM? 16:33:35 .. Meaning that the results we get might be wrong because the ISD creation step was inconsistent across 16:33:39 .. implementations. 16:35:04 Nigel: My concern is that there are too many unknowns. 16:35:18 .. We have no defined semantic for combining ISDs from different IMSC documents, 16:35:29 .. so we cannot point to a source of error if there is one. 16:35:45 .. I think we could reasonably say "here are the rules for ISDs generated from one IMSC document, 16:36:00 .. and if you have a way of combining ISD sequences from multiple documents, that's fine, you can 16:36:16 .. run the algorithm on that, but we can't tell you what's wrong because it's out of our scope". 16:36:57 Pierre: In my mind it's been straightforward because ISDs have a duration and you just stack them. 16:37:00 Nigel: That's not enough! 16:37:06 Pierre: Maybe that's where the disagreement is. 16:37:24 Nigel: You have to have rules for dealing with overlaps. 16:37:43 .. We haven't ever defined that. Something like EBU-TT Live does. 16:37:54 Pierre: In my mind you would never do that because there would be an ambiguity. 16:38:06 .. You could say "a non-overlapping sequence of ISDs". 16:39:08 Nigel: You have to know how the inevitable overlaps are generated. 16:40:02 Pierre: You could say that the overlaps have to have been resolved. 16:40:14 Nigel: But then that resolution depends on some algorithm we haven't specified and don't know. 16:40:25 .. We can't assess conformance given an important missing step. 16:41:01 Pierre: We could require that the test inputs are single IMSC documents, synthesised from ISD sequences. 16:41:07 Nigel: That would be fine. 16:41:17 Pierre: That would remove the need to deal with overlap. 16:41:24 Nigel: Yes, we need to move overlap resolution elsewhere. 16:41:42 Pierre: So in my mind the algorithm is purely about a sequence of ISDs, and we don't care where they come from, 16:41:51 .. but in testing we only test single IMSC documents. 16:43:30 Nigel: I think we should put all the overlap resolution and recombination into an IMSC document outside the spec, 16:43:45 .. instead, the input is one IMSC document that generates the sequence of ISDs, and that one document 16:43:47 .. is a pass/fail. 16:44:02 .. And we can note that some folk might have schemes where there are multiple IMSC documents that 16:44:21 .. generate multiple ISDs, and that's great, but they have to be responsible for generating an IMSC documewnt 16:44:29 .. that generates the equivalent sequence of ISDs. 16:44:40 Pierre: Okay I can take a stab at that, I think I understand, thanks. 16:45:00 SUMMARY: @palemieux to draft an edit as per the above discussion. 16:45:05 s/documewnt/document 16:45:21 Topic: DAPT 16:46:16 Nigel: Cyril, any points to raise to the group? 16:46:29 Cyril: Mainly same as last time, editing continues. 16:46:35 .. We can talk about the profile issue. 16:46:56 .. Nigel, I'm working on your notion of transcript still! 16:47:10 Nigel: Yes, there are two pull requests that both deal with those in different ways. 16:47:52 Cyril: Yes, the first pull request didn't define the terms and was tricky to understand. 16:48:17 Nigel: If it would help I can merge the two pull requests so you can see the changes all together. 16:48:20 Cyril: Yes, go ahead. 16:48:45 Subtopic: ttp:profile on root, and conformance terminology w3c/dapt#104 16:48:53 github: https://github.com/w3c/dapt/issues/104 16:48:54 https://github.com/w3c/dapt/issues/104 : ttp:profile on root, and conformance terminology 16:50:04 Cyril: I'm happy that we're digging into this but we need to make it easy for new folk to understand. 16:50:18 Nigel: I think #103 is improving this. 16:50:31 Cyril: From a video world, having two profiles is confusing and we need to clarify it. 16:50:43 .. They don't know about processor profile vs content profile. 16:51:12 Nigel: This issue came from a conversation with Glenn about some things I wanted to do that 16:51:15 .. TTML2 didn't seem to allow. 16:51:27 .. The starting point is TTML1 backwards compatibility. 16:51:34 .. For DAPT, we simply aren't interested in that. 16:51:52 .. We only want to use contentProfiles and possibly optionally processorProfiles, but not ttp:profile 16:52:15 .. but all the relevant feature designators in TTML2 include the TTML1 #profile, and effectively require 16:52:29 .. implementers to code for ttp:profile even though we are prohibiting its use. 16:52:47 .. Glenn proposed a way to express this in the formal language of TTML2 profiles, which I've done 16:53:27 .. in #103. It essentially defines an extension for this one thing and says "this is prohibited". 16:53:46 .. There's a message from Glenn that I haven't read yet about TTML2 handling of different values of the 16:53:52 .. value attribute on the ttp:feature element. 16:54:30 .. The essence is we want to be able to say "it's permitted in a document, and must be implemented in a processor" 16:54:46 .. which doesn't seem possible in TTML2. I think he's pointing me at something I missed. 16:55:01 Cyril: Every standard has that, optional features that must be supported by the player. 16:55:04 Nigel: Of course! 16:55:13 Cyril: I'm not clear about this processor profile part. 16:56:18 Nigel: One of the things I've done is move the profile definition into the appendix, still normative, 16:56:41 .. but kept the important/interesting stuff that we need people to understand to before the appendices. 16:56:51 .. It keeps the formality but makes the document seem shorter. 16:56:55 Cyril: I like that idea. 16:57:30 Nigel: At the moment I've had to define a content profile and a processor profile distinctly, 16:57:44 .. and it'd be much better if we could have only one. I will keep working with Glenn to understand if 16:57:47 .. I can actually do that. 16:58:06 SUMMARY: @nigelmegitt to continue talking to @skynavga about how to simplify this. 16:58:17 Topic: AOB - next meeting 16:59:05 Nigel: Next meeting is scheduled for 2023-01-05. I can't make that. 16:59:14 Cyril: I also sent regrets for that. 16:59:20 Gary: Might be worth cancelling. 16:59:30 .. I think a lot of people are out so there won't be much to discuss anyway 16:59:44 Nigel: Okay I'll cancel and our next call will be on 2023-01-19. 17:00:13 Topic: Meeting close 17:00:55 Nigel: Thanks everyone for all your work this year and for suffering through the great TTWG Charter fiasco. 17:01:03 .. Have a good break, look forward to seeing you next year. 17:01:10 Cyril: Thank you for your chairing! 17:01:19 Gary: Yes, thank you. 17:01:24 Pierre: Warmest wishes for the holiday season. 17:01:54 i/P/Atsushi: Thank you. 17:02:01 Nigel: [adjourns meeting] 17:02:06 rrsagent, make minutes 17:02:07 I have made the request to generate https://www.w3.org/2022/12/22-tt-minutes.html nigel 17:24:18 scribeOptions: -final -noEmbedDiagnostics 17:24:33 Present+ Cyril 17:24:36 zakim, end meeting 17:24:36 As of this point the attendees have been Nigel, Pierre, Gary, Atsushi, Cyril 17:24:38 RRSAgent, please draft minutes v2 17:24:39 I have made the request to generate https://www.w3.org/2022/12/22-tt-minutes.html Zakim 17:25:16 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 17:25:16 Zakim has left #tt 17:31:16 rrsagent, excuse us 17:31:16 I see no action items