16:00:14 RRSAgent has joined #tt 16:00:14 logging to https://www.w3.org/2022/11/10-tt-irc 16:00:15 RRSAgent, make logs Public 16:00:16 Meeting: Timed Text Working Group Teleconference 16:00:30 Agenda: https://github.com/w3c/ttwg/issues/232 16:00:37 Previous meeting: https://www.w3.org/2022/10/27-tt-minutes.html 16:01:34 Present+ Nigel, Gary 16:01:40 Chair: Gary, NIgel 16:01:44 Chair: Gary, Nigel 16:03:28 Present+ Cyril, Pierre 16:05:32 Topic: This meeting 16:07:45 group: [discussion of zoom access, URLs, the ability to use W3C zoom] 16:07:55 Atsushi: I will send the Chairs an email about W3C zoom 16:07:57 Nigel: Thank you 16:10:08 Nigel: Today we have DAPT, a couple of points on IMSC-HRM, and if there's a status update on the 16:10:19 .. charter FO Council, we can take that too. 16:10:25 .. Is there any other business? 16:10:39 Pierre: On IMSC-HRM I would like to cover CR Exit criteria - I created a Pull Request. 16:10:47 Nigel: OK, thank you 16:11:14 group: [no other business] 16:12:07 pal has joined #tt 16:12:18 Topic: Rechartering Formal Objection Council update 16:12:22 Nigel: Anything to report? 16:12:47 Atsushi: I just know that the Council is set up and they're working to coordinate on the time of the meeting 16:12:56 .. so nothing further has happened. 16:13:06 Nigel: Thank you. Any questions? 16:14:47 Topic: IMSC-HRM 16:14:50 Subtopic: Plan to reference IMSC-HRM from future revisions of IMSC? 16:15:34 Nigel: This comes from a comment in w3c/imsc-hrm#51 where Pierre said he thought we 16:15:35 https://github.com/w3c/imsc-hrm/issues/51 : If referencing from IMSC, references will be circular 16:15:44 .. should not reference IMSC-HRM from IMSC. 16:16:30 .. First question: are you saying we should remove the normative requirement to meet IMSC-HRM from IMSC? 16:16:47 Pierre: Yes, that's correct. It would remove that from conformance in future editions of IMSC. 16:17:03 Nigel: The argument is that it's not used? 16:17:12 Pierre: Two arguments. A) to avoid the circular reference. 16:17:27 .. B) It won't have a significant difference because organisations that want to enforce 16:17:35 .. the HRM have called it out separately. 16:17:43 .. I don't think it will cause an impact in practice. 16:17:54 .. We can always have a note in IMSC that points to IMSC-HRM, e.g. 16:18:07 +1 for informative note to inform, consumer can choose to apply both or only imsc 16:18:11 .. saying "this spec does not impose any constraints on presentation complexity, here's where to find it". 16:18:55 Nigel: This raises the question of if IMSC-HRM needs to be a Rec track document? 16:19:12 Pierre: To the extent that other orgs would use it for conformance I think they would appreciate it being 16:19:25 .. a Rec track document. To a large extent it depends on those external organisations. 16:19:36 .. I know some that would be reluctant to reference a WG Note for instance. 16:20:11 Nigel: And the positive reason for removing from IMSC - is it only to avoid the circular reference? 16:20:27 Cyril: Why is it a problem to have circular references? Other specs do that a lot - almost every standard in ISO! 16:21:14 Nigel: We've always tried to be clear about the chain of dependencies from spec to spec, and avoided 16:21:18 .. circular references. 16:21:42 .. That was my next question too, is this the only way to avoid circular references? 16:22:16 Atsushi: I'm curious too - I believe this is something that humans can check, for circularity, 16:22:35 .. e.g. if A defines in terms of B and B is defined in terms of A. That can even be in one specification. 16:22:45 .. It cannot easily be detected automatically. 16:23:31 Nigel: That's right, there are ways to deal with this. Also, can IMSC-HRM stand on its own, or can 16:23:35 .. it be used only for IMSC. 16:23:49 Pierre: It's a constraint on IMSC, the dependency is pretty obvious that IMSC-HRM depends on IMSC. 16:24:06 .. For better or worse, for many implementations, renderers have implemented IMSC but not the HRM validation. 16:24:17 Pierre: I think circular references are bad simply because they're circular. 16:24:32 .. I don't want this to be an obstacle. If there's a desire to have a circular reference I'm not going to 16:24:37 .. no-vote the document. 16:24:58 .. Imagine: circular refs are bad because if IMSC gets updated without updating IMSC-HRM, then you don't 16:25:15 .. go back to where you started if you follow the reference. Sometimes that's harmless, sometimes harmful. 16:25:33 .. Being serious about conformance. which some orgs are, then we would have a separate conformance 16:25:41 .. document. 16:25:47 Nigel: That would be the IMSC spec though? 16:26:08 Pierre: Not always. I'm simply advocating having IMSC-HRM reference IMSC, and have an undated 16:26:13 .. reference from IMSC to IMSC-HRM. 16:26:35 .. Maybe later we'll have a spec on readability complexity for Western European languages, as a separate spec. 16:26:48 Nigel: I'd like two things to happen: 16:27:11 .. 1. We arrange it so that the decision about how to reference IMSC-HRM from IMSC is made separately, 16:27:16 .. which means: 16:27:41 .. 2. We word IMSC-HRM so that it can be referenced normatively from IMSC, if that's what we some time want. 16:28:25 .. An easy way to deal with this circular reference is to duplicate the definition. 16:28:34 Pierre: That is an editorial nightmare - I'd object to that. 16:28:44 Nigel: Is it though? Is it worse? 16:29:10 Pierre: Yes, it causes work. 16:29:22 Nigel: My argument is that a change to one doc doesn't then require a change to the other, because 16:29:30 .. the definition has document-level scope only. 16:29:46 Pierre: I'd prefer circular references than defining the same term twice in two different specifications. 16:29:51 .. I've never seen that end well. 16:30:41 Nigel: I'm thinking that carefully arranged circular references might be the best option here. 16:31:17 .. My original issue was that there should be no circular references _that cannot be resolved_, so if we 16:31:25 .. can check that, it should be fine. 16:31:36 Pierre: I think the references are undated now, so I think it will work. 16:32:31 Nigel: Let's say we make some tweak to a defined term in a future version of IMSC, can we make 16:32:47 .. it so that the reference to that term in IMSC-HRM is to the one for the version of IMSC that applies? 16:32:59 Pierre: We should try to avoid doing that and if we do, we should do it very carefully. 16:33:10 .. One could argue that we should reference a particular version of IMSC. 16:33:22 .. Nowadays in practice people look at the latest version. 16:33:35 .. The responsibility would be on us, if we make a substantive change to a definition or something 16:33:50 .. depended upon in the spec, then we better warn people, it could be disruptive. 16:34:12 .. Like changing glyph buffer Gn to glyph back buffer is really editorial, but it we were to change 16:34:26 .. Presented Region that would have a negative impact and we might want to define a new term instead. 16:34:38 Github: https://github.com/w3c/imsc-hrm/issues/51 16:35:10 Pierre: Not to be philosophical, let's not make a new version of IMSC that's incompatible with an old one! 16:35:15 .. I've seen that in other specs. 16:36:12 SUMMARY: Keep the references circular for the time being, and check that they can all be resolved successfully. 16:36:29 Pierre: We can defer this until we revise IMSC to reference IMSC-HRM. 16:36:57 Nigel: No, I want us to make sure we don't put something in IMSC-HRM that gives us a problem later. 16:37:07 Pierre: I'm not aware of anything that gives us that problem right now. 16:37:17 Nigel: That may well be the case. 16:37:57 SUMMARY: Nigel to verify that the current text will not cause any issues. 16:38:40 github-bot, end topic 16:38:56 Subtopic: CR1 exit criteria w3c/imsc-hrm#56 16:39:01 https://github.com/w3c/imsc-hrm/pull/56 : CR1 exit criteria 16:39:11 github: https://github.com/w3c/imsc-hrm/pull/56 16:39:39 Nigel: This is a draft PR, maybe that's why I did not notice it ahead of the call. 16:39:51 Pierre: Walking through this. 16:40:58 Nigel: [shares https://github.com/w3c/imsc-hrm/pull/56/files?short_path=37df7cf#diff-37df7cf5e1fb2c2cfdd1d6eed9ffb1ddaa7070ffc160a1bf1aa717ecf60db1cc on screen] 16:41:13 Pierre: I thought adding a MD doc was a good way to kick around ideas. 16:41:24 .. This lays out how we will demonstrate Implementation Experience. 16:42:06 .. The idea is that each IMSC document is accompanied by an assertion that says if it passes or fails. 16:42:18 .. The idea is that each document is tested against each implementation and we determine that it 16:42:27 .. meets the assertion. 16:42:44 .. Features at risk: it occurred to me that the current implementation of imsc-hrm does not support 16:42:56 .. image profile, because nobody has asked for it. Unless we can find actual image profile documents, 16:43:09 .. from people who use it at scale, we should just remove that feature from IMSC-HRM 16:43:24 .. Then there's a bunch of synthetic tests to test the boundaries and features of the HRM. 16:43:35 .. If we are happy with this structure, then I'll add more synthetic tests. 16:43:42 .. That's my proposal for exit criteria. 16:44:01 .. Atsushi asked if we want exit criteria to be different for each CR version. 16:44:19 .. In the past I have found that CR exit tests are not necessarily useful for the community, long term. 16:44:31 .. Right now the synthetic tests are just in a directory. 16:44:36 Cyril: Two questions. 16:44:46 .. First, the collection of sample IMSC documents. 16:44:56 .. I'm wondering, e.g. for Netflix, how we can contribute them, for IP reasons. 16:45:12 Pierre: Thanks for the offer! I would expect Netflix to run the implementation internally and just report 16:45:19 .. on the results, I would be satisfied with that. 16:45:27 Cyril: Okay, that makes sense. 16:45:36 .. Second, do you have a list of features that you want to test? 16:45:48 Pierre: Not yet. There are different ways the HRM can be exceeded, 16:45:59 .. maximum glyph buffer size, maximum rendering time. 16:46:08 .. You'd want a test for each of those. 16:46:16 .. There's also IPD, a maximum render time, to test. 16:46:32 .. We should also test failure on the first ISD of a sequence, because it's somewhat of a special case. 16:46:48 .. We should test the ideograms as having a different rendering rate from non-ideograms. 16:47:05 .. We should have test documentations that fail if the glyph buffer is not being used. 16:47:20 .. I am planning to clean up the tests for the implementation and make them available. 16:47:29 Cyril: I'm wondering if there's a list of those features? 16:47:40 Pierre: Yes, we could add a feature test column. 16:47:54 Cyril: In other standard bodies we're working on having explicit references from the spec to the tests. 16:48:14 .. Tools like bikeshed or respec help, they can generate assert ids, which you add with special markup 16:48:36 .. in the spec text. Then you can use those in the naming of the tests. 16:48:47 .. Respec has a way to show you the tests, if you cross-reference them properly. 16:48:54 .. It may be worth investigating. 16:48:59 Pierre: Absolutely, I'll look at that, thanks. 16:49:29 Nigel: Elephant in the room - this approach is going to be dependent on the result of the FO Council. 16:50:35 .. I think we cannot finalise this approach until we have the FO Council outcome. 16:50:55 Atsushi: Usually they have a single call to arrive at their conclusions, so we may hear something at the 16:51:10 .. end of this month, at least. Of course it make take time to generate the formal document to be published. 16:51:29 .. In any case I believe we can get a decision this month if the pattern follows previous FO Councils. 16:51:46 Pierre: By definition the deliberation does not stop our work. Anyway end of month works for 16:51:51 .. timing for requesting transition to CR. 16:52:50 Nigel: For the collections of documents, you want an assertion for each document whether it passes or fails? 16:53:02 Pierre: For the synthetic ones, its our responsibility to generate those. 16:53:16 .. For third parties, e.g. Netflix, BBC, it's up to them to say whether they think a document should pass 16:53:27 .. or fail, and report whether the implementation agreed with their expectation. 16:53:33 .. If it agrees, there's nothing more to do. 16:53:42 .. If it does not agree, then we have to determine what to do. 16:54:02 .. It could be the content is invalid, an error in the spec, an error in the implementation. 16:54:21 Atsushi: One concern with building a test suite for HRM. It needs to have at least 16:54:29 .. two generated documents from different implementations. 16:54:44 .. Should there be some example of presentation? 16:55:07 .. And IMSC-HRM implementation will go over that and generate a pass/fail result. 16:55:28 .. If I am correct I think we need to have some descriptive note for our test case? 16:55:42 Pierre: My proposal is that we ask folks like BBC, like Netflix and others to test their commercial content. 16:55:56 .. That would be their criteria. Content that they use commercially or plan to use commercially. 16:56:34 .. We cannot specify any particular style, it's different for every provider. 16:56:47 .. That's what's most useful for the industry - it will tell us if the HRM is useful, and right. 16:57:12 Atsushi: Usually, just seeing it built against each API call or value definition is ideal. I'm not sure how 16:57:34 .. to convince readers of the implementation report that it covers all defined functionality in the HRM. 16:57:59 .. Like which test is related to each definition, etc. It's difficult to regenerate the cases. 16:58:13 Pierre: I agree it's different than other specs, e.g. API based specs, for sure. 16:58:26 .. We cannot control what people create commercially which ultimately is what people care about. 16:58:38 .. It does not fit the template of API specs. 16:59:36 Nigel: If we were to be able to show that the HRM is successful at selecting between content that plays 16:59:46 .. successfully on some player and content that does not, that would be really useful. 17:00:07 Pierre: We can fairly easily architect a synthetic test that presents alright but is likely to cause most players 17:00:22 .. to have a problem, and is rejected by the HRM. 17:00:32 .. Then we could invite folks with players to try it. We could do that too. 17:01:09 Nigel: That's the big unknown to me, how well the HRM tracks real world playability - that's really hard to grasp. 17:01:24 Pierre: It would be helpful actually to generate synthetic documents. 17:01:36 .. Any objection to the overall approach, before I start working on it? 17:01:54 Cyril: No, this is fine, but maybe we should wait for the FO Council? 17:02:02 .. You might waste effort. 17:02:25 Pierre: I think we can address their conclusions later. 17:03:44 SUMMARY: No immediate objections, Pierre to proceed. TTWG to continue reviewing. 17:03:54 github-bot, end topic 17:04:05 Pierre: Thanks for the feedback. 17:04:43 Topic: DAPT 17:05:25 Cyril: Suggest scheduling an editor's session 17:05:29 Nigel: +1 let's arrange offline 17:05:36 Cyril: OK 17:05:46 Topic: Meeting close 17:06:54 Nigel: We're over-time - thanks everyone. Next call in 2 weeks. [rrsagent, make minutes] 17:07:35 rrsagent, make minutes 17:07:35 I have made the request to generate https://www.w3.org/2022/11/10-tt-minutes.html nigel 17:26:21 scribe: nigel 17:26:27 Present+ Atsushi 17:26:53 scribeOptions: -final -noEmbedDiagnostics 17:26:57 zakim, end meeting 17:26:58 As of this point the attendees have been Nigel, Gary, Cyril, Pierre, Atsushi 17:27:00 RRSAgent, please draft minutes v2 17:27:00 I have made the request to generate https://www.w3.org/2022/11/10-tt-minutes.html Zakim 17:27:03 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 17:27:07 Zakim has left #tt