07:35:12 RRSAgent has joined #tt 07:35:12 logging to https://www.w3.org/2019/01/31-tt-irc 07:35:14 RRSAgent, make logs public 07:35:14 Zakim has joined #tt 07:35:16 Meeting: Timed Text Working Group Teleconference 07:35:16 Date: 31 January 2019 07:35:16 Agenda: https://www.w3.org/wiki/TimedText/F2F-jan-2019 07:35:27 Log: https://www.w3.org/2019/01/31-tt-irc 07:36:51 Present: Nigel, Glenn, Thierry, Pierre, Andreas 07:36:54 Chair: Nigel 07:36:57 scribe: nigel 07:37:50 Present+ Matt 07:39:07 glenn has joined #tt 07:45:07 Present+ Gary 07:50:15 Topic: Introductions 07:50:47 Nigel: Do we all know each other? 07:51:08 group: [almost all have met before, if only for dinner last night] 07:51:16 Thierry: I'm team contact for the group 07:51:32 atai has joined #tt 07:51:47 Topic: Agenda and working model for this meeting 07:52:03 -> https://www.w3.org/wiki/TimedText/F2F-jan-2019#Schedule Schedule for today 07:52:17 Nigel: Overall goals of the meeting 07:52:29 .. First draft for TT future requirements 07:52:41 .. First draft Charter Revision for TTWG 07:53:00 .. Since then we also want to understand the situation re WebVTT as well. 07:57:54 .. [iterates through agenda] 07:57:59 .. How does that look? 07:58:14 Glenn: I'd like a small discussion before we go through requirements to come up with categories for 07:58:32 .. assigning requirements to documents. Part of that hinges on what our thoughts are re TTML2 or TTML3. 07:58:44 .. We don't have a record of discussion of our guidelines for targeting TTML2 vs TTML3. 07:58:55 .. And for IMSC we probably need some idea of what we are targeting, a 1.2 or what. 07:59:10 .. I think it might be useful so when we go through the requirements we can refine with labels. 07:59:17 q+ 07:59:22 .. I've been trying to go through those issues and assign labels where appropriate. 07:59:31 .. I think it would be useful before we go through the requirements. 07:59:34 ack at 07:59:49 Andreas: Two ways to approach - what Glenn said, or what Nigel proposed to go through requirements 08:00:05 .. first and then go through the documents. I prefer what Nigel proposed. I think it makes sense to go 08:00:21 .. through the requirements and see for each one which documents they go in. I would start as soon as 08:00:25 .. possible with the requirements. 08:00:39 Glenn: It might require a second pass through the requirements after we make decisions about 08:00:49 .. document targets. I'm not opposed to that approach. 08:02:11 Nigel: We should make sure we think about documents to target for each requirement we want to meet. 08:02:33 .. We can label at the time or later after the notes. 08:02:57 Glenn: That's okay but we need to have some thought about which features can go into TTML2 2nd Ed 08:03:23 .. vs TTML3. In my mind substantive new features need to go into TTML3 whereas substantive or 08:03:33 .. editorial clarifications can go into TTML2 2nd Ed. 08:04:00 Glenn: Yes with the proviso that there may be a grey area, if we forget we need to add a keyword value 08:04:14 .. for an existing property, or a feature designator. Those could potentially be in TTML2 2nd Ed. 08:04:21 .. New properties or elements are clearer. 08:04:47 Nigel: Also we could consider TTML2.1 for new features. 08:05:07 Glenn: I'd oppose that because we decided in the past not to use dot releases in TTML. It would either be 08:05:14 .. 2nd edition or TTML3, not TTML2.1 08:05:45 Nigel: What about IMSC, are we looking at new features going in IMSC 1.2? 08:05:54 Pierre: Depends what they are and on the impact on conformance. 08:06:23 Nigel: Everyone happy with how we target version numbers for TTML? 08:06:34 Andreas: Yes, I think we need to see as we go through. 08:06:44 .. The important thing is we decide to publish by the end of the year. 08:07:02 Glenn: That's also my goal, I'd like to get to Rec on TTML2 2nd Ed by the end of the year but also on 08:07:36 .. TTML3 which would depend on implementation activity and may slip later. 08:08:08 .. Some of these new features are out of my expertise so we would depend on implementers. 08:08:11 Nigel: As always! 08:08:17 Glenn: Yes, and testing also. 08:09:04 Nigel: I would rather defer features and publish on time than let it slip. 08:09:30 Glenn: I would like to get to CR by June 1, and hope to go direct to PR. 08:10:11 Nigel: That reminds me Thierry was going to draft a sketch timetable for getting to publication. 08:10:14 c/CR/FPWD 08:10:39 Thierry: Yes I will do that, based on FPWD on 1st June. 08:10:49 Glenn: Modularisation might change that, we need to discuss that. 08:11:01 .. It's a huge amount of editing work so the editors will bear the brunt of that. 08:11:49 Thierry: For my schedule, if there are no substantive features then it is straightforward because it does 08:11:59 .. not change the implementation report. It could be fast tracked. 08:12:07 Glenn: Both documents will have substantive changes. 08:14:00 Nigel: Any more questions about today? 08:14:17 Andreas: Our goal for the TTWG Reqs is to decide for all of them if they will be in the next TTML or IMSC 08:14:21 .. publications, today? 08:14:34 Nigel: Yes, I think so. 08:14:42 Andreas: Just to make sure we get through all of them! 08:15:41 .. And the target is not to find a solution for the requirement, just to support the requirement itself? 08:15:53 Nigel: I think if we have no idea how to meet the requirement then we probably won't be able to do it, 08:16:05 .. so we should have at least some idea of what the solution might look like. 08:17:39 Topic: WebVTT Implementation Report 08:18:22 tmichel has joined #tt 08:18:31 Gary: [Shares screen] 08:18:43 -> https://docs.google.com/spreadsheets/d/e/2PACX-1vSHzJtwi_2ijdV7hRUH0Fe8qZeSwMaCLErK7w7U_IFzhzNmW9YwPRWrER1eHR9-4Eo0kqyXJ4G35b1b/pubhtml# WebVTT implementation report starter 08:19:03 Gary: I used WPT as a basis. Unfortunately some of the tests require human eyeballs and can't be automated 08:19:08 .. so they're not showing in here. 08:19:25 .. Some of the tests are grouped by feature, where multiple tests together make up a feature rather than 08:19:31 .. each test being a feature in itself. 08:19:41 .. This is partly because of the way WebVTT is written. 08:19:54 .. For example a Cue includes multiple features. 08:19:59 .. It's doable but not really clear cut. 08:20:15 Andreas: I think from the WebVTT spec there are parts you can categorise like the Cue settings. 08:20:27 .. It might make sense to do that, and then check each value. 08:20:40 .. Also for pseudo-selectors and all the CSS features that are supported, like color etc. 08:20:54 Gary: For the CSS stuff there is a bunch of different ways of selecting parts of a cue, so there are like 08:21:20 .. 20 different tests for each one. Five tests for how text wrapping is handled. It's not necessarily a 1:1 08:21:24 .. correspondence. 08:21:35 Andreas: Would you also test that color is rendered correctly for example? 08:22:11 Gary: Yes. There are three color tests, for hex, hsla and rgb. 08:22:26 .. Some of the cue functions are not supported. They may be relatively new additions which is why they 08:22:36 .. are not supported. It is often the case that newer things are less supported. 08:23:02 Glenn: On the spreadsheet the first line says "VTTCue Align" - is that testing the align property? 08:23:28 Gary: That's a folder name, which contains the two tests underneath it. 08:23:45 Glenn: I don't see any align property testing there, so it's confusing. Is the align property tested? 08:24:17 Gary: I think it is in there. The "align" one is the top one. 08:24:27 Glenn: You might want to change the naming to make it clearer. 08:24:39 Gary: yes, I'm looking at the second tab for rendering tests. 08:24:58 .. There are Pass and Fails and some ?s where we don't know. 08:25:11 .. The ?/F are likely to fail but I'm not sure yet. 08:25:20 .. The ?/P are likely to pass I think. 08:25:33 Present+ Silvia 08:25:49 Gary: There are some changes to the spec since the FPWD and they seem to be involved with those I'm 08:26:12 .. not sure about. One of the things we may need to do is update the tests for those things. 08:26:19 Silvia: It's a limited set, not a huge list. 08:26:35 Gary: Regions are one of the areas that needs work. 08:26:43 Glenn: I see most of the entries are blank there. 08:27:22 Gary: Yes, Firefox preview does some strange things with defaults. 08:27:28 .. VLC does better but I'm not sure. 08:27:39 Silvia: I think VLC might implement correctly but the tests need to be updated. 08:28:01 Glenn: What is the strategy for all-fail tests? Will you take out features from the spec? 08:28:26 Gary: I feel like it might be better to remove features that have no support and then work on the next 08:28:32 .. version to add them back. 08:28:41 Glenn: Another strategy is to remove the tests. 08:28:45 group: [laughter] 08:29:07 Glenn: There's nothing that defines what is tested. The WG can define what tests are used. 08:29:12 q+ 08:29:22 ack atai 08:29:38 Andreas: I'm not sure if this was a serious proposal. If we have important features we should test them. 08:29:57 .. The process is there for a reason to give some fidelity for implementers to show that there are 08:30:12 .. implementations out there. This spreadsheet is really great. To remove tests that fail and then push the 08:30:28 .. specs through containing those features that we know are not implemented correctly does not make sense. 08:30:53 Glenn: For a given feature, which I understand are not enumerated, what tests are mandatory to call it 08:31:08 .. a tested feature is not determined. If there's at least one test for a feature we can claim the feature 08:31:24 .. was tested. Some of us might claim the tests were inadequate, and they might be right. Process-wise, 08:31:28 .. this is in the realm of the possible. 08:32:38 Nigel: I recall a couple of years ago David stated the group did not want to remove features, and I think 08:32:57 .. that was partly for things like regions where there seems to be an FCC requirement for them. 08:33:14 Gary: We need some way to move forward. 08:33:40 Silvia: It's a bit of a chicken and egg thing, persuading implementers to implement. Some implementers 08:33:42 q+ 08:34:08 .. wait for Rec before going ahead. 08:34:25 .. In the case of regions there are implementations but not interoperable ones, or they have bugs. 08:34:34 .. So we could take the feature out for the time being. 08:34:40 Pierre: Or wait for the bug to be fixed. 08:35:29 Gary: Because of the lack of uptake and implementation we may need to do something else. 08:36:20 Matt: We use VTT as a lowest common denominator because of the lack of support for any detailed 08:36:37 .. features beyond text and time. If there is serious work to address the implementation gaps it would be 08:36:40 .. worth publicising that. 08:36:45 ack at 08:37:08 Andreas: Silvia said possibly some potential implementing parties like browsers might wait for spec 08:37:29 .. stability before implementing. This would possibly be a reason for publishing not fully implemented 08:37:48 .. features. I see that WebVTT has been published for a long time. The strategy was always to have a living 08:38:03 .. spec that tracks the implementations. I see that elsewhere. They are often fully implemented before CR. 08:38:23 .. It is just an overhead to go further. Therefore I think it is possibly wise what Gary said, to look at what 08:38:38 .. we have, see if there are quick fixes, take features out to get to publication, and if there is interest and 08:38:52 .. expectation for new features, put them in the next version. 08:39:05 Silvia: Maybe it makes sense if we expect those features to evolve and change. 08:39:26 .. The region spec particularly has evolved a lot. We have a poll in the sand now for what we want to 08:39:55 .. implement, and scrambling (slowly) to do that. The way I look at this spec is we are putting a pole in the 08:39:58 s/poll/pole 08:40:23 .. sand for the FCC required regulatory features. We went through a rigorous process to get to here. 08:40:39 .. Nigel has been helpful and everyone else in the WG in making the spec better. 08:40:54 .. I don't foresee any of the existing features making any changes. The next step would be adding 08:41:08 .. functionality that isn't there. It would make sense to take everything there to Rec. We haven't 08:41:23 .. finished checking if we have interoperability, with the JS libraries, VLC etc. 08:41:37 Pierre: I don't understand what you're proposing. It cannot be published if we haven't demonstrated 08:41:52 .. interop by at least 2 implementations. 08:42:01 Nigel: It has to meet the CR exit criteria. 08:42:16 q+ 08:42:22 Glenn: I'm not so sure, I think publish as is to draw the line in the sand. If you roll back the test coverage 08:42:36 .. to get minimal testing of features I see that as a good option for moving forward even if some people 08:42:53 .. don't like that. It's been extremely painful to get this far. It will be a lot of editorial work to haul out 08:43:12 .. features. Also on Microsoft since they're switching to chrome basically that takes one implementation 08:43:24 .. off the table and you end up with Chrome and Mozilla as the implementation paths. 08:43:44 .. Is there an option to pass tests by polyfill? 08:44:29 Pierre: Why are we doing this? To demonstrate interop, right. This is at CR already, it's already published. 08:44:46 Andreas: I would support what Pierre said. It's not a problem to publish for stability. 08:44:52 Thierry: CR is a call for implementations. 08:45:06 Andreas: Exactly that. If this does not happen then it stays in CR. 08:45:28 Thierry: I'd like to focus on the WG task here. It's not up to the WG to decide on moving to PR, That's 08:45:45 .. the Director's decision. Our task is to motivate why features are not passing tests and make the case 08:46:00 .. to the Director who will decide if it passes the exit criteria and decide whether to move to PR. 08:46:23 .. The second thing, about removing features, could be very time consuming and also delay the spec a 08:46:39 .. lot. If we move things out we need to publish a new CR with at risk features listed. The current doc 08:46:46 .. says there are no at risk features. 08:47:33 .. A new CR doesn't take a long time. But then there will be a lot of work for re-editing the spec, 08:47:51 .. removing the feature, and we don't know the impact of that, which is not an easy task either. 08:48:09 .. The last thing is currently the Charter expires in 14 months from now and WebVTT is mentioned in 08:48:24 .. that Charter. If we don't touch it we could wait for a year, but if we do a new Charter then we have 08:48:44 .. to convince the Project Lead, Philippe le Hégaret, to include WebVTT in the new Charter. 08:49:16 .. We have to remove features, or make the case for moving to PR, or add to a new Charter. 08:49:23 q+ 08:51:11 Nigel: David already established we have consensus to stop work on WebVTT if we can't move it forward. 08:51:45 .. I think the easiest path forward is to complete the implementation report. 08:51:53 Silvia: How long do we have? 08:52:03 Thierry: In this scenario we're in, about a month. 08:52:21 Silvia: I'm concerned we might not have time to do it. 08:52:33 Gary: I have not tested VLC yet, or the polyfills. 08:52:46 Thierry: To make life easier, why don't you focus on the features not implemented in other browsers, 08:52:58 .. those where you don't have enough implementations yet. 08:53:05 Gary: yes that makes sense 08:53:18 Thierry: That focuses to 20-30 tests. 08:53:21 q? 08:53:49 Gary: Additionally some tests can be fixed in vttJS and I planned to open issues on chrome and Firefox. 08:53:55 .. Some tests also need fixing. 08:54:09 Silvia: videoJS and JWPlayer have implementations to test too. 08:54:14 Gary: They both use vtt.js 08:54:17 Silvia: Ok 08:54:35 Thierry: You only need to test feature by feature. 08:54:45 ack a 08:54:50 ack g 08:55:01 Matt_Simpson has joined #tt 08:55:07 Glenn: One small point. I heard Thierry say we could crank out another CR quickly adding only at risk 08:55:22 .. features. That would provide a path for moving to PR without requiring another CR if you were to 08:55:43 .. remove those features. A change only to the status section wouldn't require a new WD. 08:55:47 Thierry: That's right. 08:57:00 .. It's a possibility but doesn't answer the question. 08:57:19 Nigel: We've only got one Gary, so I think it makes sense to prioritise the implementation report. 08:57:29 .. We don't even know which features to list as at risk! 08:57:44 Silvia: Gary do you think we can have a full report by the end of February? 08:57:50 Gary: Yes I think I can make the case for that. 08:58:22 Silvia: Some features have multiple tests so it would make sense to group them, and collapse some tests 08:59:25 .. together. I think I heard before that if there are multiple tests they don't all need to pass. 08:59:36 Nigel: All the tests in the report need to have at least two passing implementations. 09:00:30 .. The goal is to demonstrate implementability not interoperability. 09:00:50 Pierre: What we're trying to do is make sure the spec is implementable, so if the spec is clear and you get 09:00:56 .. different results then there's something wrong there. 09:01:16 Thierry: The Director is not going to check if all the features in the spec are tested. It's up to the WG to 09:01:19 q+ 09:01:31 .. decide if we are covering the features. If we have corner case tests then it's our decision to remove it. 09:01:40 Pierre: Or if the spec is ambiguous, worse. 09:01:43 ack a 09:02:08 Andreas: It's important that the WG understands this process. I think it makes sense what is proposed 09:02:27 .. to go through and structure the tests as Silvia said, and check against other implementations, and then 09:02:47 .. decide on it. In general if a feature has not enough implementations that could be feedback for the spec. 09:02:56 .. If we have the results then we can decide how to judge. 09:03:15 Thierry: In some cases we need to understand why the test is failing. It could be a bug, or an unclear spec 09:03:32 .. where implementers disagree on the correct result. That is very different from lack of implementation. 09:03:46 .. Two different results based on different understandings should be a red flag. 09:05:27 Nigel: We're running to the end of this agenda topic. I think we have consensus to move ahead by 09:05:37 .. completing the implementation report over the next month. 09:05:54 Thierry: Specifically to check non-passing features against other implementations like VLC. 09:06:07 .. I would like to thank Gary for taking this on. 09:06:19 Gary: Thank you. The third task is that a couple of tests may need to be updated. 09:06:23 Silvia: That's true. 09:06:38 .. I would start there if I was you, so you can run those tests. 09:06:46 .. Thanks everyone, I'm going to go. 09:06:54 .. [leaves] 09:07:13 rrsagent, make minutes 09:07:13 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 09:07:22 Nigel: Let's take a break for 5 minutes. 09:18:45 Topic: TTWG Future requirements 09:20:06 The first one is issue 1: 09:20:19 Topic: Resolve open issues in ttml2 repository. tt-reqs#1 09:20:24 github: https://github.com/w3c/tt-reqs/issues/1 09:21:03 Nigel: Is there any more detail we can add to this now? 09:21:17 Glenn: No, not that I know of, unless we want to go through the 73 issues. 09:21:23 .. I need to start processing them right away. 09:21:40 .. Quite a few of them are small, some were pushed forward that may not be so small that I need to 09:21:44 .. start on. 09:21:52 Andreas: Do we take it as a given that we solve them all? 09:22:04 Glenn: As many as possible. If we have favourite ones then ping me. 09:22:14 Pierre: Timetable? 09:22:22 Glenn: June 1 for FPWD of 2nd Ed. 09:22:36 Pierre: One meta-issue is setting limits on values. 09:22:46 Glenn: Implementation limits? 09:22:54 Pierre: Maximum number limits like on seconds. 09:23:05 Glenn: We have some in the spec already, from TTML1 1st Ed. 09:23:24 .. We haven't really pushed specifying limits. I think feature definitions would be the best place. 09:23:40 .. For example something that says how many colors are supported. 09:23:49 Pierre: Right, a specific example is number of seconds. 09:23:54 Glenn: We haven't said anything about that. 09:24:08 Pierre: 32-bit or 64-bit. That's a ton of work, so we need to decide on that. 09:24:14 Andreas: Does it cause problems? 09:24:35 Pierre: It has caused problems, because someone had used media time origin as 1970 and that blew 09:24:49 .. up an implementation which didn't allocate enough bits to the number of seconds. 09:24:56 Nigel: We do that sometimes! 09:25:07 Pierre: It turned into a more complex problem than at first it appeared. 09:25:15 Glenn: We don't have an issue on this, do we? 09:25:31 Pierre: Maybe on TTML1. It could be a feature designator for minimal support, say. 09:25:40 Nigel: Sounds like a good idea to me. 09:26:00 Glenn: We couldn't retro-actively apply it to TTML1. The ship has sailed. 09:26:22 .. They would be in the range of a semantic restriction of an existing feature. 09:26:28 Pierre: We can introduce new features. 09:26:32 Nigel: Yes we can. 09:27:41 .. Take it further - if a processor feature says 32-bit number of seconds then does that invalidate content 09:27:53 .. with time expressions that could go beyond 32-bit numbers? 09:28:09 Pierre: We began to touch on this in the TTML1 issue. 09:28:46 Glenn: Say we define a limits feature and define a 32-bit one. Absent such a feature in the processor 09:28:52 .. profile it would effectively be undefined. 09:29:21 .. Then in a content profile I don't know what it means. 09:32:15 -> https://github.com/w3c/ttml2/issues/1023 Constrain maximum value of @length on data element. ttml2#1023 09:32:47 -> https://github.com/w3c/ttml1/issues/307 Least upper bound on supported time expression values. ttml1#307 09:32:55 Pierre: what's the view on this? 09:33:04 Nigel: I want to know more about the implementer pain levels 09:33:17 Pierre: We know at least about time expressions causing pain. 09:33:26 Andreas: I would support doing it for time expressions 09:34:22 Nigel: We can ask others of course. For example I can imagine DVB implementers wanting to know this 09:34:24 .. detali. 09:35:18 Nigel: Coming back to the macro requirement, are all the substantive issues for 2nd Ed? 09:35:25 Glenn: We haven't created a TTML3 repo yet. 09:35:49 Pierre: There are a couple tagged for TTML.next and 2nd Ed milestone but don't belong in 2nd Ed. 09:36:02 Glenn: Can we get a new repo for TTML3? 09:36:12 Nigel: Yes I don't see why not if that's how you want to do it. 09:37:31 -> https://github.com/w3c/ttwg/issues/23 Create TTML3 repos ttwg#23 09:37:36 Nigel: I've assigned that to Thierry 09:38:05 Glenn: I need to triage these. Most of the ttml.next ones need to get pushed to TTML3. 09:38:24 Pierre: Can you do this now so we can go over them this afternoon. It would be awesome if we can go 09:38:36 s/go/get 09:38:41 .. get a good idea of it today. 09:38:53 Glenn: I didn't come prepared for that. 09:39:10 Andreas: If nobody has missed a feature and filed it then it may not be a candidate for TTML3 09:39:16 Glenn: I don't understand 09:39:33 Andreas: We opened requirements up and if nobody raised requirements for missing features then you 09:39:37 .. could argue they are not in scope. 09:39:55 Pierre: We can't leave "resolve all issues in TTML2" open today 09:40:14 Glenn: That was a catch-all requirement. 09:41:02 Andreas: I agree with Pierre we need to go through them today. 10 substantive features coming in would 09:41:08 .. change the whole picture. 09:41:18 Pierre: Can you make a first pass? 09:43:55 https://github.com/w3c/ttml3-tests and https://github.com/w3c/ttml3 created 09:46:34 Glenn: I can't do a first pass today, I can go through it this evening and change ttml.next 09:46:45 .. to ttml3 where it's my first approximation and the group can confirm it tomorrow. 09:46:59 .. If I think there are things for 2nd ed then I'll mark that too. It'll take me a couple of hours. 09:47:16 Pierre: The most important is to change the milestone. 09:47:45 Glenn: Once we have the TTML3 repo I need to transfer them to that repo. 09:48:04 Pierre: You can transfer issues on GitHub if you're an owner 09:48:07 Thierry: oka 09:48:16 s/oka/okay 09:48:25 Glenn: I promise not to make any other changes under the covers! 09:49:41 Nigel: Summarising, it is clear which specs are being targeted. We don't have consensus yet on which 09:50:18 .. things to adopt, pending a more detailed review. 09:50:52 Nigel: For the substantive changes I want to get an idea of what the test will look like. 09:51:12 Glenn: In a preliminary basis we can describe at a high level the kind of things we need to see tested. 09:51:27 .. For example HDR images would require images with HDR coding in them. That's a high level test. 09:56:07 ttml2 and ttml3 repos : added Glenn and Nigel as Admin. 09:56:18 Pierre: Can we change this specifically to TTML2 2nd Ed and constrain it to editorial features? 09:56:32 Glenn: We could add a ttml3 tag and include moving new features to ttml3. 09:56:41 Pierre: Just this one requirement. 09:56:53 Andreas: It makes sense to fix bugs in 2nd Ed, we don't need a big discussion. 09:57:08 .. All new features are new requirements so I expect them not to be in TTML3. If there are important 09:57:16 .. ones then they need to be submitted, but that period is over. 09:57:21 Pierre: I totally agree. 10:01:36 group: [discussion of handling this requirement issue] 10:02:11 Glenn: I will change the issue title to Resolve open issues to TTML2 2nd Ed. 10:02:16 Pierre: thank you 10:03:12 SUMMARY: TTML3 issues to move to new repo, this issue to cover TTML2 2nd Ed changes only, @skynavga to triage issues. 10:03:46 github-bot, end topic 10:04:27 Topic: Support live contribution of TTML tt-reqs#3 10:04:55 Nigel: Given the agenda I think we can only scan through this now and will need to come back to it tomorrow. 10:05:03 Pierre: Do you see this as a core part of TTML3 or an add-on? 10:06:21 Nigel: Good question. I would happily see this as a TTML3 module for dealing with sequences of 10:06:37 .. TTML documents arriving over time and define any additional syntax and semantics that are needed. 10:06:45 Pierre: Then that can be adopted independently. 10:07:07 Glenn: Re modularisation, I would make fine changes to enable new modules to be layered on top of 10:07:18 .. what is already there. There are issues like namespace, conformance processing, the document 10:07:32 .. processing module that can be tweaked to enable these without making in-depth changes. That's 10:07:45 q+ 10:07:47 .. my thinking. What I don't want to do is to think about breaking off, say, styling, timing, animation etc 10:08:03 .. and creating N new rec-track documents for each. That would be nightmarish and not possible 10:08:20 .. within the timeframe of this year. It would enable new modules to be added on like this which would 10:08:26 .. be a separate Rec track document. 10:08:41 .. In regards to Charter we need to figure out if every module is a separate Rec track document. I think 10:08:51 .. the answer is Yes, if we take the CSS approach. 10:08:53 Pierre: I like that. 10:09:03 .. If a module turns out to be universally used... 10:09:08 Glenn: We can bring that back in. 10:09:28 Nigel: I wouldn't though. 10:10:05 .. If you have a Rec track document there's no advantage to bringing it in. 10:10:20 Andreas: I propose a separate module to allow live processing of TTML. 10:10:39 .. At the time of publication it is a separate module which still has the possiblity to merge later if there is a need. 10:10:41 ack a 10:10:52 .. Then for live use case I have a question about the profile and the syntax. 10:11:11 .. EBU-TT Live is a subset of TTML. I assume in the module you would not publish a profile that subsets, 10:11:20 .. just the additional vocabulary you need and a profile. 10:11:40 .. Then the question is where does it live, would you have a separate profile of IMSC that includes the 10:11:41 .. module. 10:11:55 Pierre: That makes sense. The separate module relieves the pressure on TTML, and allows the market 10:12:00 .. to react to it. 10:12:13 Andreas: You need something to experiment with, the module itself is not enough. 10:12:28 Glenn: We need a modularisation framework that enables features to be brought in. 10:12:49 .. For example a convention that allows features to be prefixed. 10:13:01 .. We need to find a way to integrate and that's part of the modularisation framework. 10:13:15 Pierre: Andreas, you're saying that if there's a module then IMSC still needs to be modified? 10:13:18 Andreas: Yes 10:13:30 Pierre: What if we don't know it is useful at the beginning? 10:13:38 q+ 10:13:55 Andreas: There's no implementation of the complete set of TTML2. There is a need to say what it is used 10:14:00 .. together with, in practice. 10:14:09 Pierre: Sure, unless it is completely outside the scope of IMSC. 10:14:25 Andreas: The benefit to have it now in W3C scope is to use it together with something standardised by 10:14:40 .. W3C which is IMSC. Otherwise the situation does not change and we get to EBU-TT Live. 10:14:57 .. In EBU-TT Live you have timebase clock supported for example which is not in IMSC. I think it makes 10:15:11 .. sense to discuss tomorrow if IMSC and this module can be brought together. 10:15:26 Glenn: Right now we have two namespaces, one for core and another for extensions. Each module could 10:15:41 .. define its own feature namespace URI and define minimum requirements for integration into other 10:16:01 .. profiles that use that module, and say for example that profile foo needs to support minimal feature set. 10:16:10 .. And in addition define new features for labelling the module as a whole. 10:16:35 .. That's part of what I was thinking about with the framework. 10:16:36 ack n 10:19:03 Nigel: I have a concrete example here which is a prototype of what Glenn describes, in the TTML in RTP 10:19:18 .. IETF proposal, where we will be adding a processor profile that defines an extension feature describing 10:19:21 .. how the times are handled. 10:19:39 q+ 10:19:40 Pierre: I have no objection to adopting this requirement especially if this is a separate module. 10:19:50 Glenn: It makes it easier if other Editors can take on modules. 10:19:53 ack a 10:20:10 Andreas: Tomorrow we can come back to this but it now makes sense for EBU to contribute EBU-TT Live 10:20:20 .. as the basis for a new module. I think everything is already written. 10:21:04 Nigel: I agree, there's editorial work needed, and probably we should write less than what is in EBU-TT Live. 10:21:25 Glenn: Presumably the existing work is in an EBU namespace. I've objected to bringing into the TTML core 10:21:34 .. foreign namespaces but I won't to doing so in a module. 10:21:47 .. It would create a possible block to incorporating into the core in the future. 10:22:06 Nigel: That's useful. 10:22:18 Glenn: It might make is easier and improve interoperability too. 10:22:22 Nigel: +1 10:22:58 Pierre: One last thing. Who is going to be the Editor here, because I don't think we can accept a requirement 10:23:03 .. for which there is no resource. 10:23:05 Glenn: Good point. 10:23:26 .. I see two decisions. One is to make it a module pending a modularisation framework, and two is 10:23:33 .. designating an editor, and it won't be me. 10:24:22 Nigel: It's up to the Chair to designate Editors, and I am happy to designate myself as well as anyone 10:24:28 .. else who wants to additionally do it. 10:26:13 SUMMARY: Consensus at this stage to proceed with this requirement, as a new Rec track module to be Edited at least by @nigelmegitt. 10:27:26 Nigel: I think we need a Charter addition here to allow us to define new Rec track documents as part of 10:27:36 .. a modularisation approach. Thierry will that likely be okay? 10:27:38 Thierry: Yes. 10:27:52 .. Do you want also to be able to define profiles as well as modules? We can add that too. 10:28:05 Glenn: I view it as the base module definitions will define features and then those can be used by 10:28:13 .. profiles as needed. The profiling system supports that. 10:28:32 atai has joined #tt 10:29:38 SUMMARY: Add option for modules to the draft Charter 10:29:42 github-bot, end topic 10:30:05 rrsagent. m 10:30:13 s/rrsagent. m/ 10:30:19 rrsagent, make minutes 10:30:19 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 10:51:55 Topic: Audio Description profile of TTML2 tt-reqs#4 10:52:00 github-bot: https://github.com/w3c/tt-reqs/issues/4 10:52:00 nigel, Sorry, I don't understand that command. Try 'help'. 10:52:04 github: https://github.com/w3c/tt-reqs/issues/4 10:53:03 Nigel: This is for a Rec track profile of TTML2 (or TTML2 2nd Ed) based on the existing work in the AD CG. 10:53:20 Andreas: So the idea is first to publish a new document which would be a profile like IMSC is a profile, 10:53:32 .. and to make any additions or tweaks in TTML to make it fully compatible. 10:53:33 Nigel: Yes 10:53:40 Glenn: Another Rec track document basically? 10:53:41 Nigel: Yes 10:54:03 Glenn: Is there a designated Editor? 10:54:24 Andreas: Are we deciding now on the changes to TTML2 or just on this document. 10:55:05 Nigel: I'm not sure if there are any tweaks now, it may be that we want only to adjust the range of values 10:55:11 .. that, say, tta:gain takes. 10:55:19 Pierre: That complicates things significantly. 10:55:22 Nigel: I don't think so. 10:55:38 Glenn: It pushes it to TTML3. We can make cases for adding values if it was left out by mistake and 10:55:48 .. clearly needed to support the functionality that was implied. 10:56:20 q+ 10:56:32 Nigel: I don't think so, this is a mistake I think, where the range of tta:gain was discussed but what went 10:56:38 .. in the spec was a smaller range. 10:56:52 Glenn: That's in a grey area, it sounds like it could be fixed in 2nd Ed. 10:56:56 act a 10:57:02 s/act a// 10:57:19 Andreas: I added to the issue the f2f meeting of the AD CG because there were a lot of interesting ideas. 10:57:27 .. I'm not sure how much they would be in scope for the proposed document. 10:57:30 ack a 10:57:45 Andreas: For example having more on the required processor behaviour. 10:58:06 .. It's clearly not in TTML2 yet so the question is if you see this in scope for this new rec track document 10:58:13 .. and if it would be more a new module than a new profile. 10:58:23 Glenn: It sounds like there may be more impact than just one document here. 10:59:10 Nigel: Yes I think so. The semantics are informatively described in TTML2 so we could either make them 10:59:29 .. normative and more detailed in TTML2 2nd Ed or make them normative in the profile. 10:59:44 Andreas: It would be good to get a harmonised approach with browser manufacturers so they could 10:59:49 .. implement the same or a similar concept. 11:00:05 glenn has joined #tt 11:00:08 .. Also something not in TTML2 is that a processor needs to pause the video if there is not enough time 11:00:12 .. for the descriptions. 11:00:21 Nigel: That's a good point. 11:01:03 Andreas: I want to check that this is in scope of the work. 11:01:20 Nigel: Yes the profile could say something about playback behaviour, which is beyond the scope of TTML. 11:01:40 .. In terms of the Editor question, at the moment John Birch is editor in the CG, and I can ask if he is able 11:02:26 .. to continue that here - he is a member of TTWG. I'd like to make myself an editor but am worried about 11:02:41 .. the effort needed to do it, and chair, and look after the live subtitle work. 11:03:02 .. We do have an editing opportunity here for anyone who wants to take it on, I think. 11:03:19 Pierre: It sounds like we don't have a commitment at this point? 11:03:27 Nigel: At the moment John is editor of that profile. 11:03:47 .. There was a stated intention in the CG to move this to the TTWG so that won't be a surprise. 11:03:50 Pierre: Great. 11:05:55 PROPOSAL: Accept this requirement for TTWG work in 2019 and add to the 2019 Charter. 11:06:02 Nigel: Any questions or comments before I finalise that? 11:06:08 RESOLUTION: Accept this requirement for TTWG work in 2019 and add to the 2019 Charter. 11:06:18 Nigel: I've moved the milestone on this issue also. 11:06:22 github-bot, end topic 11:06:50 Topic: Fade in/out tt-rews#11 11:06:55 s/rews/reqs 11:07:02 github: https://github.com/w3c/tt-reqs/issues/11 11:07:15 Andreas: This has been contributed by someone who works in the field of subtitles. 11:07:39 .. We have to ask if it is already solved, and if there is already some syntax or mechanics, is it appropriate 11:07:47 .. and user friendly enough to be used for the requested feature. 11:07:54 q+ 11:08:08 Glenn: I asked the original commenter two weeks ago for further input asking if they believe there is 11:08:25 .. something not accommodated by TTML2. I haven't heard anything back since Dec 20 it looks like. 11:08:31 q+ 11:08:43 .. My current assumption is there is no technical feature being asked for, possible a desire to support 11:08:56 .. in IMSC. I think we can close this issue. We can reopen it if the commenter comes back. 11:09:02 ack nigel 11:11:05 Nigel: I see there's no response from the commenter. I also observe that there is an overlap here between 11:11:21 .. this, the karaoke and the CSS extensions requirements, so it may be that we meet the requirement 11:11:34 .. by reference to one of those others. If it is needed I think it would be needed in IMSC also. 11:11:45 .. It is not obvious to me how this can be done in a user friendly way at the moment. 11:11:48 ack a 11:12:06 Andreas: Glenn said that he asked Pablo Romero Fresco if he agrees that TTML2 already meets the 11:12:25 .. requirements or if he objects. As he did not respond then he would like to close the issue. I encouraged 11:12:42 .. Pablo to file this issue because he has the requirement and he is not familiar with TTML2. I also saw 11:12:56 .. some value in what he requested. I also said to him that if he's not familiar with the technology then 11:13:01 .. I would help out which I'm happy to do. 11:13:10 .. First I also support this requirement and would not like to close it. 11:13:24 .. The important thing for now is to say this requirement should be met by TTML or IMSC. 11:13:41 .. I would support that. Until we have not proven that it could be met by existing vocabulary then it 11:13:59 .. should not be closed. I agree with Nigel that the current spec text does not satisfy it completely, 11:14:04 .. especially in a user friendly way. 11:14:23 .. How this is done is a separate issue. I can imagine some dedicated vocabulary like fadeIn or fadeOut. 11:14:38 .. Most important is to bring this into scope, for now I would leave it open. 11:14:48 Pierre: Did you see the example that Glenn provided? 11:14:52 Andreas: Yes 11:14:57 Pierre: Is that too complicated? 11:15:17 Andreas: Pablo asked for key frames and control over the speed so I'm not sure if this is enough. 11:15:31 Glenn: We have spline and keyframe and interpolation modes. All that is being asked for is present. 11:15:44 .. User friendliness is not a criteria that we have applied to any of this technology up to now. 11:16:02 .. For me this needs a champion within our group, who would be responsible for determining the answer. 11:16:07 Andreas: I will champion this. 11:16:41 Glenn: I probably would not be inclined to support new shorthand properties for this but you could make 11:16:57 .. the case that it is some higher level thing that could be translated into TTML syntax. 11:17:11 .. I don't mind leaving it open if there's a champion. 11:17:29 Andreas: I am happy to do it. I think you're right that we need a balance for user friendliness, and we may 11:17:48 .. not need to add anything new. User friendliness does indeed play a role in TTML, otherwise there would 11:18:08 .. not be different syntaxes for, say, color, but this could be delegated to another time. 11:18:18 .. We first see if technically it meets the requirements. 11:18:42 Glenn: There is a principle at stake called Maximum Orthogonality which we have applied as a strategy 11:18:55 .. in TTML which says one should not define alternative ways to do the same thing. 11:19:01 Andreas: But we do. 11:19:39 .. One addition: I think the request is also to have this feature in a used profile of TTML and the only 11:20:12 .. one I know is IMSC, so there would be a request to add it there. 11:20:29 Glenn: On this particular issue there was some back and forth on labelling, I guess we can leave this 11:20:38 .. open for the time being if you are going to take it forward Andreas. 11:21:14 Andreas: Yes, there's no real policy on labelling so it does not represent a decision and I'm fine with any labels. 11:21:29 Glenn: I didn't have an objection to Nigel's change here so I didn't make any noise on this issue. 11:21:41 Pierre: In terms of the requirement is it on IMSC to support this at the end of the day? 11:21:46 Andreas: Yes 11:22:02 Pierre: The challenge I have is who will make the implementation effort to make it happen? 11:22:16 .. Is the one interested party the tip of the iceberg or is that it? 11:22:33 Andreas: I heard it also from other directions. Although it may not be a super critical feature. 11:22:36 q+ 11:22:43 Pierre: I think we need those users to show up somehow. 11:23:01 Andreas: The question of how we measure the weight of the feature - often it is sufficient if one member 11:23:06 .. presents the case. 11:23:26 Pierre: I haven't heard form Movielabs on this. 11:23:41 Glenn: I haven't heard from Netflix on this. 11:24:02 Nigel: There's an interaction here with responsive, CSS, karaoke: essentially we need to be able to specify 11:24:17 .. or interpolate word timings and have some presentation effects dependent on those. 11:25:45 q+ 11:26:07 .. I think Cyril suggested time markers which could be relevant too. 11:26:31 Glenn: Once upon a time we had a different timing model in TTML presented by John Birch and that took 11:26:47 .. a lot of time, which in the end we had no implementations for. What you're bringing up now is 11:27:03 .. asking if we need some small amount of that. I'm open to thinking about it again but it's a complicated 11:27:21 .. area for sure. Writing in processing semantics for such heuristics is not straightforward. 11:27:37 .. In the context of karaoke I think we are going to run into this again so I think we will have to bite the 11:27:43 .. bullet and look at it. 11:27:44 ack a 11:28:01 Andreas: I hear what Pierre is saying and that there needs to be sufficient support for new features, so 11:28:17 .. I would ask if other stakeholders would take it up, and if they think it is needed. It needs a balance of 11:28:25 .. workload in what we can achieve this year. 11:28:47 .. I think that counts of course for every feature. I would also look at the HTML group's process for how 11:28:52 .. they consider new features for adoption. 11:28:59 Pierre: We have to have this input. 11:29:17 Glenn: Here's a link for dynamic flow 11:29:27 Pierre: What do we do before we have critical mass of interest? 11:29:42 Andreas: I would leave it open for now. 11:29:58 Pierre: The question is do we schedule it for 2019? I would object to it unless we know there are people 11:30:08 glenn has joined #tt 11:30:09 .. who will be testing it, implementing it, paying for it. 11:30:10 https://www.w3.org/TR/2010/CR-ttaf1-dfxp-20100223/#style-attribute-dynamicFlow 11:30:33 .. In the case of IMSC we have checked it is really what industry wants to do. 11:30:39 Andreas: OK I will check that. 11:31:17 Nigel: We wanted to come to a decision here but at the moment we don't have consensus to proceed 11:31:23 .. with it or to say no. 11:31:34 Andreas: What is the process if we do not have a consensus on a feature. 11:31:38 q? 11:32:00 Nigel: I propose that we proceed with this but note for ourselves that there is additional risk associated 11:32:25 .. with this feature, which can be mitigated by getting more adoption or implementation input. Actually 11:32:46 .. this risk applies to everything we do, but in this case it has been flagged up early. If we don't get 11:33:06 .. enough input on this then the default should be we defer it until such time as we have enough. 11:33:19 Pierre: How long will it take Andreas to get additional feedback? 11:33:30 Andreas: End of March because I will be out of the office most of February. 11:33:52 Pierre: Can we make it earlier if there's strong interest? 11:34:54 Nigel: When we come back at the end of today we will have looked at karaoke and other additions and may 11:34:57 .. have a change of view. 11:35:13 Pierre: Right now I think we can't accept it. By the way I'm not questioning the applicability, as this is used 11:35:16 .. today in digital cinema. 11:35:28 Andreas: I think Nigel's compromise is a good one for now. 11:35:37 Pierre: I'm saying that one person alone is not enough. 11:36:05 .. If we can't get input on this until end of March let's not schedule it for 2019. 11:36:23 Glenn: Some groups like CSS have an implicit operating rule which is to say that if no browsers implement 11:36:44 .. then nobody will pay any attention to it. We should do something similar with respect to the content 11:36:58 .. community, and if we have insufficient interest then it is not adequate. 11:37:16 Andreas: Whatever approach we take it is quite similar, if we don't take it in now but take it in later. It is the same thing. 11:37:35 .. For me there is not a clear basis and transparent basis for external people, when a feature has 11:37:52 .. sufficient support and backup to be expected. We now discuss it, so we do not have a clear statement, 11:38:00 .. and until then we cannot just say now we need more. 11:38:15 Pierre: Ultimately it is the consensus of the group, the AC and the Director that counts. 11:38:33 .. It could be that at the end of March this is a high priority thing. 11:38:47 .. I would rather say without closing it that we don't schedule it in 2019 and revisit it when there's 11:38:57 .. more input, which could be tomorrow, next week or at the end of March. 11:39:14 Glenn: I want to remind everyone that new technical requirements need to be accompanied by test content. 11:39:53 Andreas: I'm not happy with this, and maybe process-wise we need to deal with the case where we do not 11:40:01 .. have consensus. Does that mean it is out of the list? 11:42:21 Nigel: Consensus does mean no objections, normally. Here I think the only objection is due to lack of 11:42:39 .. perceived interest, which could change. I mean, the BBC's requirements include transition effects too. 11:42:45 .. They're in the CSS requirement. 11:43:22 Andreas: I could take this if we apply the same rule to everything else. I cannot accept introducing new 11:43:37 .. barriers now. We said that the requirements would be open for a certain time but we didn't say more. 11:43:53 Glenn: The Chair is responsible for determining whether we have consensus and also whether to overrule 11:44:10 .. an objection, and if he declares consensus in the presence of an objection then there's an appeals process for that. 11:45:45 Nigel: That's correct in terms of process. For this specific thing I think we need a checkpoint later like 11:46:09 .. FPWD where we know for certain if we have enough resource and input, and if we don't then we defer it. 11:46:26 .. There are at least 2, maybe 3 or 4 sources for this requirement. 11:46:44 Glenn: This requires TTML3 for significant features. We could easily put an example or a note in TTML2 2nd Ed 11:46:59 .. describing how to use animation features in for fade in or fade out, giving us some place to point to 11:47:05 .. for people who ask questions about it. 11:47:17 .. I think I have somewhere an open issue that says "add more animation examples" so I may already have 11:47:23 .. an issue for that, in the 75 open issues. 11:48:14 Pierre: I don't agree putting this into IMSC in 2019 given the current level of backing today. 11:48:20 Glenn: I would support Pierre's position on this. 11:48:29 Pierre: I don't think it should be closed though, just not scheduled. 11:49:06 Nigel: Okay so we can still make progress and schedule it in for 2019 later if there is backing. 11:49:26 Pierre: I agree. There's huge testing effort but probably it is straightforward from a specification perspective. 11:49:36 Nigel: Andreas, can you live with that? 11:49:39 Andreas: Yes 11:50:05 SUMMARY: Not currently scheduled for 2019, pending additional input of resource to test and implement. 11:50:16 github-bot, end topic 11:53:15 testing 11:53:18 tm has joined #tt 11:53:31 nigel_ has joined #tt 11:54:48 slightlyoff has joined #tt 11:55:27 atai1 has joined #tt 11:55:39 Nigel: There's been good debate here. The function is in wide use especially in Europe, and we have 11:55:46 .. some support in TTML2 but not for IMSC. 11:56:15 .. I think the gap is in signalling. 11:57:06 Matt: The use case is for blind or partially sighted people which would typically be subtitled not being 11:57:40 .. able to read the translation. Some broadcasters can transmit the text, say in Dutch, for the box to 11:58:00 .. present as an additional audio track, so a Dutch speaker listening but unable to read the words on screen 11:58:27 .. would have some audio representation of the text translation of the English into Dutch. 11:58:36 github-bot has joined #tt 11:58:41 Pierre: OK, so stupid question - you could solve with alternate audio channels. 11:59:03 Matt: Bandwidth limitations mean its more efficient to deliver as text. 11:59:34 .. The TTS is done client side usually. It's a very small user group who needs this. 11:59:36 mdjp has joined #tt 11:59:51 Pierre: Assuming the client gets a TTML track, the client could do TTS on the track without any change. 12:00:10 Matt: You need some markup to distinguish ordinary captions vs text to speech 12:00:15 Pierre: Like forced but for audio? 12:00:32 Matt: Exactly. If I did this in Teletext it would be a separate stream. 12:00:33 +q 12:00:42 ack n 12:01:49 Glenn: The use cases describe TTS of existing subtitles on the client side in companion screen. 12:01:57 .. That's done, check! 12:02:04 Nigel: No way, there are loads of gaps there. 12:02:14 .. If you'd tried to implement that you'd find them. 12:02:27 Glenn: Discount the companion screen, that's out of scope. 12:02:33 .. OCR is out of scope 12:03:10 .. Screen reader is an application specific thing, out of scope. 12:03:31 .. 4th bullet is confusing because it talks about speech to text, which doesn't make any sense. 12:03:40 .. The last one is application level and out of scope. 12:03:54 .. I conclude that we don't have anything to do here because everything is out of scope. 12:04:17 Nigel: I don't agree on all of those things, I think you've thrown them out of scope too easily. 12:04:53 .. Take TTS of existing subtitles, this is conditional and we don't have any way to signal in the TTML 12:05:19 .. which text needs conditionally to be spoken. Even if you take out the semantic description, we still 12:05:24 .. need a syntactic option. 12:06:30 Peter_IRT_ has joined #tt 12:07:07 .. Screen readers are interesting because we don't provide any guidance to implementers on how to make 12:07:15 .. captions or subtitles available to screen readers, and I think we should. 12:07:32 .. I agree with the others though. 12:07:41 q+ glenn 12:07:45 ack gkatsev 12:08:02 Gary: In videoJS we have something related. The audio descriptions, the descriptions kind for text tracks, 12:08:21 .. and one of our accessibility people, when the audio description is displayed on the screen we allow 12:08:37 .. screen readers to read it, whereas by default we don't allow screen readers to read captions. 12:09:00 .. We allow people to have screen readers read out those captions. 12:09:15 .. And so a potential solution is instead of marking up particular cues in the TTML file for reading aloud, 12:09:29 .. have a direction to say that if something needs text to speech, provide a separate file. 12:09:48 Pierre: That's the direction industry has taken for forced subtitles. 12:09:58 Gary: Then it would be a standard TTML file with appropriate labelling. 12:10:09 Andreas: The question is if the labelling should be in the TTML or outside. 12:10:15 Gary: Easier outside probably. 12:10:56 Pierre: For forced narrative many folk wanted it inside the TTML, the direction is to have separate files. 12:11:12 Nigel: I would take the opposite view which is to support the player not processing multiple files simultaneously, 12:11:25 .. so in BBC we prefer the forced approach. 12:11:28 ack gl 12:11:43 Glenn: You said a few minutes ago there is no supported syntax but I disagree with that. We have the 12:11:53 .. extensible ttm:role and ttm:role and general metadata. 12:12:04 q+ 12:12:07 .. It is a huge mistake to start trying to push application semantics into the core of TTML language and 12:12:22 .. we should resist that every time it comes up. However if there is a consensus in the content industry 12:12:37 .. on particular metadata that helps with interoperability then it would be reasonable to propose modules 12:12:46 .. that define application specific metadata in that regard. 12:12:47 q+ 12:13:08 .. It would be a big mistake to put this into the core of the language. We have to find a balance between 12:13:25 .. standardisation and innovation on the part of the industry. Some standardisation occurs by writing down 12:13:43 .. existing practices and others on speculating on the industry need. The latter fail so my guidance is 12:13:49 .. extreme caution. 12:13:50 ack a 12:14:09 Andreas: First, maybe it makes sense to separate it because if you have a TTML file and give it to a client 12:14:24 .. you usually give it to a rendering application for subtitles which wouldn't do audio rendering. 12:14:36 .. The other question to you Nigel is how you see the overlap with the audio description module, because 12:14:49 .. the target audience is the same and the goal is very similar. 12:14:50 ack n 12:15:40 Nigel: Good point. I find it very difficult to distinguish this use case from audio description. 12:16:03 Matt: I 100% agree and struggle to understand what other than practice would change. 12:16:21 Pierre: Lots of systems do silly things like deployment issue. 12:17:19 q+ 12:19:20 q+ 12:19:23 Nigel: From a metadata perspective, there's a gap there for driving presentation behaviour because we 12:19:37 .. don't do that with metadata. We may want to add a ttm:role value for "translation" which is absent now. 12:19:48 .. If we handle this as AD only then there's nothing to do. 12:20:06 .. If we handle it as interleaved, then the TTML2 condition construct could be used based on an application 12:20:28 .. parameter that says "play back translations", then a conditionalised style that includes tta:speak to trigger 12:20:33 .. TTS of that content. 12:20:37 ack at 12:20:54 Andreas: I would like to propose that we transfer the main part of the request to the AD module and see 12:21:07 .. how it could be solved by that. There is certainly a request to add a metadata feature to TTML2 to 12:21:29 .. identify the relevant parts. We not only need so much scope on the rendering part, it is possible to label 12:21:41 .. on the production side and decide later how to render and play out as audio. That could be the path 12:22:02 .. for us. Outside our group it would be useful to have a workflow overview that shows how to use TTML. 12:22:06 ack gl 12:22:35 Glenn: The use of metadata to affect presentation semantics - I agree we have avoided that for core 12:23:00 .. semantics but I don't draw the same line for application level semantics, so I wanted to make the point 12:23:24 .. that it may be appropriate to define metadata or additional namespace qualified vocabulary not useing 12:23:28 s/use/us 12:23:48 .. our metadata at all. The question is if it is worth standardising on it and if there is a community that 12:24:23 .. can agree to a common set of meaning. That's where pushing innovation is dangerous. 12:24:44 Nigel: There is signalling in HTML and DVB for example and this is in wide use, it's not just innovation. 12:24:58 Glenn: There is precedent with forced for writing application semantics into the condition system. 12:25:15 Pierre: I suggest we summarise what we think the requirement is. We arrived at something a lot more specific 12:25:23 .. to summarise on the ticket. 12:25:37 .. I didn't hear anyone say we should not do this, so I think we should accept it and move on. 12:26:39 SUMMARY: We think the requirement here is to signal translations, and describe (potential) workflows for triggering TTS based on translations. 12:27:07 Glenn: I would like to confirm that speculation with the author of this issue. 12:27:17 Pierre: We should ask the commenter if they agree, that sounds good to me. 12:27:21 Nigel: I'm happy to do that. 12:27:46 SUMMARY: Check with @porero 12:28:32 SUMMARY: Flag timed text as a translation so that it can be used to drive text to speech. 12:28:55 Pierre: On much modern content there is both a caption file and a translation subtitle file, the latter is 12:28:58 .. 100% translation. 12:29:13 Matt: In that scenario the caption file would just be descriptions of sound effects. The two would interleave. 12:30:03 Pierre: In this definition, what's the difference, couldn't you just text to speech all the translation subtitles? 12:30:14 Gary: That's my question, do we want to limit to hard translations? 12:30:30 Matt: That goes back to Nigel's comment about a player constraint on one TTML file being active. 12:30:49 .. In that case there needs to be a mechanism of identifying what content needs to be spoken. 12:31:05 Glenn: We decided not to interleave languages in the same file. 12:31:10 Nigel: This is all same language though. 12:31:34 Glenn: For me it is an application policy. If you're authoring in TTML you might use different stages and 12:31:44 .. merge them upstream or downstream. 12:33:09 Glenn: I don't agree to anything until I hear a better description of the requirements. 12:33:33 Pierre: I think someone should write down what we think the requirements are and go back to the submitter. 12:33:38 Nigel: I'm happy to do that. 12:34:03 SUMMARY: @nigelmegitt to try to recast the requirements as per the TTWG discussion and check in with @porero. 12:34:52 github-bot, end topic 12:34:58 rrsagent, make minutes 12:34:58 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 13:18:19 tm has joined #tt 13:36:09 glenn has joined #tt 13:39:06 Topic: Review backlog issues for IMSC tt-reqs#14 13:39:15 github: https://github.com/w3c/tt-reqs/issues/14 13:39:30 Pierre: I'd like to narrow this to 2nd Edition of IMSC 1.1 rather than a new edition. 13:39:40 .. I don't think "review backlog" is a requirement. 13:39:55 .. We can fix errors and apply editorial improvement, but permitting embedded image is a brand 13:40:09 .. new requirement that would potentially be IMSC 1.2 or IMSC 2, so on this one we should deal with 13:40:12 .. editorial errors. 13:40:26 .. That's #465 and #469 for example. 13:41:24 .. Just like we said for TTML2 2nd Ed earlier. 13:41:30 Nigel: I just added #469 to the issue. 13:42:07 .. And removed #82. 13:43:02 .. Shall we just say we'll do this? 13:43:09 Pierre: Yes I'm happy to schedule this for IMSC 1.1 2nd Ed 13:43:16 Nigel: Do we need to do it in IMSC 1.0.1 too? 13:43:24 Pierre: No we should not touch that now. 13:43:26 Nigel: OK 13:43:39 .. Any other views on this? Do we have consensus to proceed? 13:43:52 RESOLUTION: Proceed with this requirement in IMSC 1.1 2nd Ed. 13:45:05 Topic: Add generic CSS property functionality tt-reqs#2 13:45:15 github: https://github.com/w3c/tt-reqs/issues/2 13:47:33 Nigel: [summarises requirement] 13:47:53 Glenn: The title says "CSS property" which I'm happy to see because it does not say "CSS Selectors". 13:48:09 .. I want to confirm here that the ask does not include CSS selectors, which would make things enormously 13:48:13 .. more complicated. 13:48:24 .. I can see a straightforward path to supporting CSS properties. 13:48:27 Nigel: What's that path? 13:48:34 Glenn: 1. Put it in a separate module. 13:49:03 .. Define a new attribute tts:cssStyle= and then a value space that is a set of CSS properties, and define 13:49:28 .. the semantics so that if both apply in some circumstance then the TTML property... we'd have to 13:49:49 .. establish a priority for when there's an intersection, let's say tts:color and tts:cssStyle="color: XXX;". 13:50:07 .. If a system did not support the CSS style mechanism then I would presume that the TTML property applies. 13:50:22 .. If it supports the CSS property applies then the CSS property could be designated to win, but I'm open 13:50:28 xq+ 13:50:32 .. to it being the other way around. I don't have a strong opinion on that. 13:50:34 q+ 13:50:41 .. That would be the simplest path. 13:50:46 s/xq+// 13:50:55 ack a 13:51:08 Andreas: That sounds like a feasible approach. Two comments also on the thread. First, we need to make 13:51:23 .. sure that there's really a defined behaviour if you apply CSS properties inside the TTML style and layout 13:51:42 .. system so that there is a deterministic rendering behaviour. That does not have to be true always because 13:51:57 .. TTML does not rely on CSS but on XSL-FO. The second thing is I would like our long term strategy 13:52:12 .. to align TTML and CSS. We had discussions with CSS WG 2 years ago and we had agreement to bring 13:52:22 .. it closer however it may look. The target was TTML3 at that time. 13:52:43 .. I think this first idea could be a transition phase. In general it would be worthwhile to meet the CSS WG 13:52:56 .. about this approach and in the long term plan consider how CSS could be handled, if it could be a way 13:53:07 .. to make timed HTML rather than TTML. 13:53:33 Glenn: I would like us to limit the scope of this particular requirement to what the title says, which is 13:53:47 .. adding generic CSS properties. Andreas it sounds like we're on similar thinking in that regard, details 13:53:58 .. to be worked out. What I do not want to mix in with this is any discussion of general long term 13:54:11 .. migration to a new as yet defined language that would not be TTML if it is intended to diverge from 13:54:23 .. an XML based language. I do not want to include that in this issue. 13:54:40 .. I don't object to someone opening a new issue defining a timed version of HTML5 with a migration 13:54:54 .. path from TTML but in my opinion that's not part of TTML standardisation, it is part of a new language 13:55:10 .. that could potentially be done in this working group. It would certainly require a new Charter entry, and 13:55:26 .. strong buy-in from the content community. Personally I think it's a bad idea and would divert precious 13:55:41 .. resources from an already diverse implementation field by introducing yet another language 13:55:55 .. ostensibly with the same goals but a different syntax. If that ever comes up under a proposal for a 13:56:10 .. new Charter Skynav will object to it formally because we don't think it is justified by the industry or any 13:56:14 .. particular use case. 13:58:35 Nigel: Thanks, Glenn that's my 3rd bullet effectively. Another is to add a feature designator, which I 13:58:40 .. don't think is contentious. 13:58:57 .. Another was to add a class attribute to allow external stylesheet support. That would need us to define 13:59:10 .. how to populate the class attribute of every element in an ISD. 13:59:52 Glenn: I think supporting external CSS stylesheets and selectors would be a step further and would like 14:00:04 .. to exclude it for now. It would make it harder to get consensus - I would object to it, for example! 14:00:22 .. I'm sort of in the middle on the properties themselves. I am trying to be amenable to your proposal Nigel, 14:00:37 .. I see the utility in having a system that facilitates rapid adoption of CSS properties without going through 14:00:50 .. a language iteration on TTML, and it would facilitate future modules where if we see a particular 14:01:05 .. property being very important we could bring it in to TTML directly as a TTML style attribute. 14:01:19 .. That would certainly enable some movement on your requirements Nigel. 14:01:34 .. It does make things complicated and creates interoperability problems, for example TTT is probably 14:01:43 .. never going to support CSS style properties. 14:01:53 .. It would have to be behind a feature for sure. 14:01:58 Nigel: That is part of the proposal. 14:02:14 Glenn: On your last bullet about precedence, it would obviously depend on whether your system supports 14:02:22 .. CSS properties. I'm open to either direction for precedence. 14:02:41 .. I feel that CSS is somewhat of an overwrite and am not convinced on that yet. 14:02:55 Pierre: What happens with inheritance? Do you inherit CSS styles like you do TTML styles? 14:03:14 .. What if the inheritance rules are not the same in CSS and TTML? What about different length units? 14:03:22 .. What's the interaction? What's the viewport? 14:03:36 Glenn: Exactly, there's a whole different terminology. 14:03:45 Pierre: Directions and padding are both different. 14:04:03 Glenn: Individual properties are challenging. Syntactically it is easy, testing is hard. 14:04:22 Pierre: The thing I have never fully understood is, in order to import additional styles, that can be done 14:04:39 .. with extension attributes, literally tomorrow. BBC can experiment to its heart's content, and if it is 14:05:03 .. successful and useful it can be added later. With a use, implementation, examples, semantics it is 14:05:57 .. trivial to add. I do not understand why this does not meet the requirement. 14:06:14 Nigel: One of the requirements is low overhead of adoption, what you're describing sounds like high overhead. 14:06:46 Pierre: From an imsc.js perspective it is always high overhead - the property has to be parsed, inherited etc. 14:07:02 Andreas: [scribe missed] 14:07:18 Pierre: The hard part is mapping the semantics of e.g. viewport related units. The hard part is not in the 14:07:22 .. syntax of the attribute. 14:07:34 Glenn: Adding the modularisation system might make it much easier to add new style properties than 14:07:41 .. has been the case in the past. 14:07:49 q+ 14:07:53 q+ 14:08:15 Pierre: Exploring modularisation, the modules can use the TT namespace, so the module can introduce 14:08:31 .. a new property, get it to FPWD, experiment with it, tweak it, then publish it, without having to change 14:08:35 .. namespace and all that stuff. 14:08:51 Glenn: This goes to the modularisation framework. We enumerate all the style properties in a table. We 14:09:03 .. are going to have to do something to make that table extensible so that we don't have to change that 14:09:11 .. table every time we add a module that defines a new property. 14:09:26 .. When we have the modularisation framework in place it should be a much easier process to push out 14:09:40 .. a spec for one or a few related properties. I can see it being used on a group of semantically related 14:09:43 .. properties. 14:10:12 .. I could see this turning into three requirements: 1. class and selector, 2. new language, 3. CSS property support. 14:10:24 .. It would be much easier to process these if we divide it into multiple issues or requirements. 14:10:26 ack a 14:10:45 Andreas: First I think what is different from Pierre and Glenn is to have a clear selection of what can be 14:10:59 .. supported specifically, i.e. which CSS properties. And then figure out what are the problems with 14:11:14 .. applying it to TTML and finding a good way to represent it syntactically. I'm not sure if we need to agree 14:11:26 .. on this today, but maybe we do need to agree today is that it is worthwhile not just to open the door 14:11:39 .. but make a selection of what needs to be supported and deal with the difficulties of each property. 14:11:55 .. I would also see it as a different module and a list of style properties. Would that satisfy your original 14:11:58 .. intention NIgel? 14:14:20 Nigel: I think it could, potentially. One other idea as a sort of middle ground is to create a module that 14:14:36 .. defines some generic ways to add CSS properties, and maybe adds some available CSS units, and then 14:14:55 .. via a registry we could whitelist specific CSS properties, adding them by consensus of this group, and 14:15:12 .. for each understanding the potential overlap and clash with TTML style attributes and how to handle 14:15:16 .. any such clash. 14:15:36 Pierre: How do you see that a registry would be less work than updating a working draft? 14:15:59 Nigel: I wouldn't propose to keep updating a WD, because that never gets to any kind of standard. 14:16:21 .. I'd propose a generic Rec and then a dynamic registry. 14:16:29 Pierre: From an implementation standpoint you haven't solved anything. 14:16:48 Andreas: What would the publishing process be for the modules? I thought they would not be Rec track? 14:16:52 Glenn: They would have to be Rec track. 14:16:55 Pierre: That's the idea. 14:16:57 Nigel: +1 14:17:07 Andreas: Then each time you want to update you have to iterate. 14:17:11 Pierre: Sure. 14:17:28 Glenn: You might have one module defining property 1 and another defining property 2 and each time 14:17:41 .. you rev that you have a certain level of work to do, but we can control the granularity. 14:17:54 .. The TTML3 document itself would need to have some framework and mechanisms to enable the 14:17:57 .. modularisation process. 14:18:00 cyril has joined #tt 14:18:11 Andreas: Then I agree if the module goes through the process then a separate registry would be duplicate 14:18:13 RRSAgent, pointer 14:18:13 See https://www.w3.org/2019/01/31-tt-irc#T14-18-13 14:18:14 .. work. 14:18:19 Present+ Cyril 14:18:38 Glenn: Let's say the CSS extensions module exists and just refers to a registry, in which we bless the CSS 14:18:44 .. properties for use. 14:18:59 .. Then there's a quasi-generic module that does not enumerate the properties but refers to a registry. 14:19:14 .. Technically speaking we don't need the registry but that gives us a process for blessing uses which 14:19:27 .. makes it better for testing. If we make it completely open ended then we have no control over testing 14:19:51 .. or blessing uses. Given there may be semantic issues with impedance mismatches to deal with. 14:20:02 Pierre: I would make it a WD that we update rather than a registry. 14:20:17 Glenn: The other option is just to define new TT style properties directly in new modules. 14:20:29 Pierre: I would go down that path from the beginning, because the work will be the same in the end, no 14:20:34 .. matter how you cut it. 14:20:48 Glenn: Then that is an alternative option, to promote fine granular modules for making extensions to 14:21:04 .. the existing suite of style properties by having, say a border style extension module and that we define 14:21:16 .. some number of tts: property names that deal with the border issues that Nigel wants to deal with. 14:21:36 q+ 14:21:50 .. The turnaround on that module could be much shorter, for, say, flex. 14:21:55 Nigel: Bad example in the context of TTML! 14:22:10 Glenn: You're right Pierre the work has to be done somewhere no matter what. 14:22:21 ack n 14:22:23 acnk a 14:22:30 s/acnk a// 14:22:51 Andreas: What is different, the work may be similar, but the turnaround time to publication is different. 14:23:07 .. The general mechanism like Nigel proposed could be done fairly easily, camelcasing and so on, and we 14:23:20 .. could bring this through the process to Rec, but if you combine it with a first list of features, then you 14:23:37 .. possibly get stuck with each feature to add. If we separate it then the general mechanism is first, and 14:23:51 .. if someone wants to do it then they can do in a standardised manner. 14:24:07 Glenn: The risk is with interop where content authors start throwing in CSS properties right and left and 14:24:20 .. make use of application specific processors and JS code to do this. 14:24:34 .. Then interoperability might decrease as a result. We would have less control over testing. 14:27:23 Pierre: The argument I hear is that the Rec track is too slow? 14:27:52 q+ 14:29:00 Nigel: Yes, we want to be able to access CSS features that already on Rec track with minimal additional delay. 14:29:13 Pierre: TTML is not HTML, you cannot just adopt CSS properties so easily. 14:29:22 Nigel: CSS is not restricted to HTML either! 14:29:42 Andreas: Concerned about time for this and other issues we have to cover. Also as an AC rep there's a 14:29:50 .. large number of Recs to review. 14:30:54 .. We haven't dealt with this modularisation yet, so we should not try to solve it now. 14:31:12 Nigel: Thanks for that, I think other organisations are interested in the requirement too but we don't 14:31:16 .. yet know the acceptable solution. 14:32:15 Glenn: I just want to make clear that if we do semantic mapping it is a non-trivial process that we cannot 14:32:38 .. put in a generic module definition. It would have to be on a per-property basis. Otherwise the only 14:32:54 .. option is to put the semantic mapping nowhere or in a registry. 14:34:05 Nigel: Where are we up to here? 14:34:20 Pierre: I haven't heard anyone speak against an easy path to adding style properties to TTML. 14:34:39 .. The obstacle to doing this on the Rec track should be minimal overhead and we're talking about how 14:34:41 .. to make it happen. 14:35:56 SUMMARY: Group agrees to look for ways to add new style properties with minimal overhead and to try to solve this in 2019. 14:37:31 Peter_IRT has joined #tt 14:37:44 glenn has joined #tt 14:38:06 Cyril: There are two parts - adding new style properties and adding the class attribute. Are they both in scope? 14:38:15 Nigel: There was some push-back against adding class 14:39:06 Glenn: The overall goal to reduce overhead is shared. 14:39:20 Topic: Add embedded image support to IMSC Text Profile tt-reqs#15 14:39:26 github: https://github.com/w3c/tt-reqs/issues/15 14:42:22 Vlad has joined #tt 14:42:27 Pierre: Remind me why fonts wouldn't solve this? 14:42:30 present+ 14:42:48 Nigel: It's not interoperable and it is not accessible. 14:44:24 Glenn: You can use private use area easily. 14:44:40 Nigel: You have to manage authoring and distribution fonts carefully. 14:44:45 .. Also there's no text alternative. 14:45:05 Cyril: You can use glyph substitution so there is a text alternative. 14:45:13 Glenn: It's implementation dependent. 14:45:35 .. You can embed the font in the document to ensure the private use area usage is consistent. 14:46:44 Nigel: If we can't use glyph substitution then you have the accessibility issue. There's no text alternative. 14:46:55 Pierre: You can put altText on the span containing it. 14:47:11 Cyril: If you have text in English how do you select altText in English. 14:47:20 Glenn: You can use it you can do whatever you want with it. 14:47:31 Cyril: Yes so you can't use it because there's no semantic defined. 14:47:39 Present+ Vlad 14:48:29 Cyril: Is glyph substitution implementation widespread? 14:48:33 Glenn: g subtable 14:48:44 Vlad: Yes it is universally implemented and supported in all browsers. 14:49:08 Glenn: So native TTML renderers or translators like imsc.js it is not supported unless you map the font 14:49:18 .. into the browser world and pass along the string, maybe it could be supported that way. 14:49:35 Vlad: Just to give me a bit better understanding of the subject, what do you think would stop this? 14:49:48 Glenn: For gaijin characters, and emerging emoji. 14:49:53 Nigel: And things like company logos. 14:50:40 Glenn: The idea is to use a downloaded or embedded font and use PUA code to map to a glyph. 14:51:09 Nigel: Or glyph substitute a set of characters like "twitter" to the twitter icon. 14:51:31 Vlad: That works - for example the word Zapfino in the Zapfino font gets replaced by a logo for the font. 14:51:55 Pierre: If you go to a text alternative as a fallback there's a bigger issue that it may require a different layout. 14:52:17 .. The entire idea of having an image fallback be unstyled simple text doesn't work very well. How do you 14:52:33 .. specify the style (color, italics) of that fallback. That's why in IMSC you have a separate file for images. 14:52:43 .. The text equivalent of image is not always what is written in the image. 14:53:12 Vlad: Remind you that fonts can have glyphs defined in SVG and that glyph can be selected when conditions 14:53:15 q+ 14:53:22 .. are right. It will still be text for all intents and purposes. 14:53:38 Pierre: When you substitute long text with one emoji that might affect the layout significantly. 14:53:40 Vlad: I agree 14:54:40 Pierre: that is a significant issue here. 14:55:00 Vlad: Rendering differences are not as bad as they used to be. Using a particular font is probably the only 14:55:16 .. way to make sure the rendering is right. Assuming that some font will be right is wishful thinking. 14:55:39 Glenn: We don't define line breaking or space distribution semantics so implementation dependent. 14:55:40 ack at 14:55:44 ack c 14:56:00 Cyril: Pierre raised an interesting point, the layout. I agree replacing a small image with 10 or 20 characters 14:56:16 .. is a big change. Focusing on the requirement, is there any objection to the requirement being agreed? 14:56:32 Glenn: I have a problem with the requirement because it is written in terms of images not text. 14:57:33 Pierre: What about recasting it in terms of glyphs? 14:57:41 Cyril: Using inline images with alt text does the trick, right 14:57:45 s/t/t? 14:58:06 Glenn: That's the traditional way with gaijin. 14:58:19 .. We have a terminology issue with Text and Image profiles each being constrained. 14:58:30 Pierre: The entire discussion so far has been really about custom characters, right? 14:59:44 Nigel: Yes, I don't think we want to support generic pre-rendered text in an image into text profile. 15:00:01 .. However the change doesn't make a substantive difference. 15:00:13 Cyril: You can put any image into the font though, right? 15:00:21 Glenn: Correct you could. 15:00:41 Cyril: You want to say that if you don't make fonts available the content of the file should be human readable and carry the content? 15:01:09 Pierre: I don't agree with that 15:01:14 Glenn: I don't see that as a requirement. 15:01:53 Cyril: I'm not sure of the requirement, we're talking about solutions. 15:02:07 Pierre: This is for visual elements as text. 15:03:16 Nigel: The only requirement that ties it to text is to size the image using the font size. 15:03:38 Glenn: Also font kerning, spacing, scaling etc are all affected by laying out as text. 15:04:32 Nigel: Recasting, the request back seems to be to support custom font embedding in IMSC Text profile. 15:04:39 Pierre: That is how it is done in ARIB-TT. 15:04:50 Cyril: I don't think it is the same thing. 15:05:12 .. This is not the gaijin character use case. That gaijin is readable, but the private use area character is 15:05:17 .. not readable. 15:05:24 q+ 15:05:27 Pierre: It can be a cartoon. 15:05:40 Cyril: It is not accessible, as Nigel explained earlier, if you don't process the font the text is still readable 15:05:43 .. by a screen reader. 15:05:46 ack v 15:06:06 Vlad: I've been listening to the discussion. As far as the requirement is concerned there are three 15:06:10 .. requirements that should be connected. 15:06:19 .. 1. Support custom fonts by embedding 15:06:36 .. 2. Support of inline images as part of text (not how it can be done, but that seems to be the requirement) 15:06:47 .. 3. (blanking out on that!) 15:07:05 .. Having font embedding functionality is a way to support inline glyphs. 15:07:27 q+ 15:07:29 Nigel: Also we need a screen reader to do something sensible here. 15:07:44 Glenn: The two options are potentially orthogonal solutions to this problem. 15:07:50 Vlad: Not necessarily. 15:08:03 Glenn: The embedded font is more consistent with treating this as text and is more compatible with the 15:08:19 .. text profile which does not include image, but as has been pointed out it might not satisfy some 15:08:45 .. screen readers but I think they are out of scope. 15:08:53 Nigel: No way are screen readers out of scope. 15:09:07 Vlad: Accessibility was my third requirement. 15:09:07 q+ 15:09:23 .. All those requirements are valid concerns and there may be one solution that satisfies them. If we can 15:09:36 .. agree on the requirements that would guide us and many other implementers on the solution. 15:09:38 ack atai1 15:09:54 Andreas: Can we bring this to a close (time)? 15:09:57 ack c 15:10:11 Cyril: I agree with Vlad's phrasing and support all three of those requirements. 15:10:26 .. We could use this heavily at Netflix. 15:11:25 Glenn: I do not agree that we have separate requirements for embedded glyph and image support in text. 15:11:38 .. They are two different scenarios for solving one requirement, which is to support the ability to display 15:11:58 .. as text some form of an image either as a glyph or an inline image characters for which there is no 15:12:12 .. standardised visual representation. There's probably something on accessibility too if you cannot 15:12:32 .. display the rendering. I view Vlad's first two requirements as two different solutions to the underlying same requirement. 15:12:35 Nigel: +1 15:13:28 SUMMARY: Solution options available, need more thought and investigation, overall requirement to find some way to present images like glyphs are presented, in an accessible way, is accepted. 15:14:06 +q 15:14:42 ack at 15:14:44 ack gk 15:14:47 s/+q/ 15:15:04 Topic: Support 3D space (360°/VR/XR) as target presentation environment tt-reqs#8 15:15:10 github: https://github.com/w3c/tt-reqs/issues/8 15:15:53 Present+ Peter_tho_Pesch 15:16:13 Nigel: Thank you for dialling in Peter, I'm going to take what you say as coming from Andreas as IRT for the purpose of IPR. 15:16:48 Nigel: Summarise the requirement please? 15:17:09 Peter: The work comes from a research project with a couple of other broadcasters, investigating 15:17:19 .. accessibility services in VR/360º environments. 15:17:27 .. We tried to put a workflow together with existing standards. 15:17:41 .. There are a few gaps. The one corresponding to subtitles I presented here. The first requirement 15:17:49 .. I put there is formulated quite generally. 15:18:09 .. The main issue is we need to find a way to refer 2D space in IMSC into a 360º or 3D environment. 15:18:24 .. It can be done technically, that's not a problem, we did it with some implementations and user testing 15:18:31 .. but there's no standardised way to do it. 15:18:51 .. We know there is more and more 360º content on the web or VR stores. They sometimes have 15:19:06 .. subtitles but the quality is often very poor so we see a need to improve it and bring the features that 15:19:12 .. IMSC has already into that new environment. 15:19:37 .. The requirement is that a way is provided that 3D environments can be used as a target rendering area, 15:19:48 .. relating the 2D subtitle into the 3D environment. 15:20:03 Nigel: Is that representing a position in 3D space? 15:20:18 Peter: Yes that's the main thing needed, and to describe what this position could be exactly. 15:20:31 .. For example if we link the centre of the rendering container to a 3D environment. 15:20:48 .. There are different approaches for that, and this is what my addition to this requirement is about. 15:21:06 .. I described what we are doing and there is another approach I described. 15:21:38 Glenn: Peter, we have in TTML2 appendix H on root container region semantics. We would have to find a 15:21:51 .. way to merge or integrate 3D into this model to make effective use of what is being proposed here. 15:21:59 q+ 15:22:05 .. Maybe it would be useful for you to review that appendix and make some suggestions for how to tweak 15:22:25 .. the model to include the Z axis, if we are talking about Euclidean geometry. 15:22:36 Pierre: It could be spherical or cartesian models. 15:22:45 Glenn: Is the proposal primarily spherical? 15:23:12 Peter: We used spherical angles to describe it but it is a matter of translation from one to the other. 15:23:26 .. We have a concrete implementation but it doesn't really matter how this is expressed. There are good 15:23:44 .. reasons for how. We need good definitions for how to standardise. 15:23:45 ack a 15:24:05 Andreas: The main part in terms of time is to focus on the decision if we want this requirement as a new 15:24:10 .. feature in TTML3. 15:24:15 .. 1. Do we understand the requirement? 15:24:22 .. 2. Is there enough backing from content providers? 15:24:28 .. 3. Are there implementations? 15:24:49 .. For the second part there is a need in the industry - maybe Vlad can come in. For implementation Peter can say more. 15:25:15 Vlad: To try to add more clarity. Looking at this issue, the use cases span over 360º video and immersive 15:25:37 .. reality. For subtitles, if we consider 360º and 2D being basically the same, you paint an object that 15:25:53 .. occludes anything else in the video. If you do exactly the same in immersive reality domain, when you 15:26:12 .. occlude something behind an object, and the occlusion is located behind the object then that's the kind 15:26:36 .. of occlusion that creates conflict in the human brain - when it happens it breaks down the perception 15:26:52 .. of the stereoscopic scene. 15:27:21 .. This is why depth position is such an important requirement for subtitles. 15:27:38 Andreas: You are also in the VR industry forum that has the issue to resolve. 15:27:55 Vlad: That is not a standards organisation, it helps guide the industry, but has a different scope. 15:28:49 Nigel: Is the requirement to identify a 3D location associated with a content element independently of 15:28:53 .. the region? 15:29:01 Vlad: Yes that is one of the requirements. 15:30:34 Nigel: Is it enough to associate zero or one 3D position and allow the implementation to do the presentation to meet user requirements? 15:30:42 Vlad: Yes, that is definitely one piece of the puzzle. 15:31:05 .. Also the content provider may want to associate an on-screen object with the character in the video. 15:31:17 q+ 15:31:20 .. For example if I want an avatar per person in the screen I may want to define that in addition to the 15:31:44 .. location, and my content may want to use that icon to associate the symbol with something outside 15:31:46 .. the viewport. 15:32:08 .. Another use case is that the content creator would want to use something as well as a directional arrow 15:32:19 .. to identify where the speaker is. 15:32:32 Andreas: Can we agree there is a requirement to add some specification text, vocabulary and semantics 15:32:39 .. to position a content element or region in 3D space? 15:33:07 Cyril: I'm not opposed, I'm wondering where the most appropriate place is, a separate module or appendix H? 15:33:25 Glenn: We have defined a pan audio property which is effectively an angle on the horizon, if you multiply 15:33:44 .. the range of -1 .. 1 by pi you get the full range. I wonder if that could be used to support the first of 15:34:01 .. the two solutions that were suggested here. I realise we defined it for audio not 3D per se. 15:34:37 Nigel: I'd almost go the other way and support audio positioning in 3D space rather than the 1D pan parameter. 15:34:54 Glenn: I would support making this a module and it may require modification to appendix H also. 15:35:11 Andreas: Is this TTML3? 15:35:26 Nigel: I think it needs TTML3 and IMSC as it has been put. 15:35:56 Pierre: I think IMSC is a longer path. There's a desire to put things in TTML before IMSC where possible. 15:36:15 .. If we want to go down that path TTWG is going to need to coordinate closely with other organisations, 15:36:31 .. I would hate to be inconsistent with other efforts. We need a champion for this. MPEG has a significant 15:36:34 .. effort there. 15:36:49 Peter: Yes we recently sent from the VR industry forum a letter to MPEG asking questions about their 15:37:10 .. suggestions for handling subtitles in 3D. They also support IMSC in their OMAF draft and I think there 15:37:24 .. are still some gaps so they try to provide that link from their side. It is true that needs to go hand in hand. 15:37:41 Pierre: The first step here is to write down what we want to do and make sure it is consistent or if not then 15:37:55 .. it is for a good reason, then once there is interest adding to IMSC is a simple editing task. 15:38:01 .. There's a lot of work to do first. 15:38:10 .. If someone is wiling to do the work, then yes, it's interesting. 15:38:15 Glenn: This would definitely be a module. 15:38:56 Andreas: IRT would possibly champion this. We already made a start with Peter working with other 15:39:09 .. standards organisations in the direction Pierre requested. We need to figure this out but possibly we 15:39:15 .. will try to push it in this group. 15:39:28 Vlad: I think that similar to previous discussion there are two separate issues. First is to agree on the 15:39:42 .. requirement and then how. It sounds like we are all in agreement this is a requirement to adopt and 15:39:46 .. how is a secondary issue. 15:40:04 Nigel: That's a nice summary, thank you Vlad. Any dissent on that? 15:40:18 Glenn: IRT would provide an editor for a module? 15:40:38 Andreas: No we haven't decided how to do that. I cannot commit to it yet. 15:41:30 .. Can we defer the editor discussion for now? 15:42:22 Pierre: OK then this is 2019 contingent on an Editor. 15:42:41 .. I don't mean someone to do typing, I mean caring about it, aligning with other efforts etc. 15:42:51 .. Someone to really make it work. 15:43:13 .. I should say a more generic champion for this rather than an Editor. 15:43:30 Peter: For me it is hard to estimate how much work it would be so I cannot commit to it now, which maybe 15:43:42 .. is what Andreas is saying, it's in our interest to follow up on this. 15:43:57 .. I see that people start to do it in one way or another and probably within the project and now after 15:44:18 .. it only works in a closed environment. It would be good to avoid letting different variations appear, which 15:44:20 .. is happening already. 15:44:29 Pierre: I share your concerns! 15:44:49 Andreas: Can we proceed with what Nigel proposed? We have interest but cannot commit today. 15:45:32 SUMMARY: Group discussed this, generally supportive, contingent on effort being available to make it happen. 15:46:37 Topic: Add support for embedded images to IMSC Image Profile tt-reqs#16 15:46:44 github: https://github.com/w3c/tt-reqs/issues/16 15:46:52 Nigel: This seems pretty straightforward? 15:48:01 Pierre: I asked a question on w3c/imsc#82 - someone called @shobanaberlin mentioned fragmented MP4 HLS. 15:48:09 .. I've received no response to my question. 15:48:24 Gary: It's in the HLS RFC. 15:48:41 Pierre: Right, fMP4 supports images so I don't understand this comment. There's literally an MPEG spec 15:48:45 .. for embedding images in MP4. 15:49:02 Glenn: What has that got to do with this requirement? Aren't you raising a separate issue? 15:49:23 Pierre: No because you don't need to embed in the IMSC document if you can embed in MP4. 15:50:21 .. The commenter asked for a way to get images in fMP4 and there is literally a spec for it so I was trying 15:50:47 .. to get more information on it. I haven't seen the use case where it is impossible to do it other than 15:51:04 .. embedding in MP4 then we could do it, but big XML documents filled with base64 encoded images is 15:51:06 .. not great. 15:51:33 Cyril: I'm with you here, there's a spec here for doing it as binary blobs, referenced by MPEG. 15:52:31 Nigel: We have a significant concern here, a better alternative way of doing it in ISO/MPEG 14496-30, 15:52:40 .. and no support, and no feedback from those who commented. 15:52:48 .. We have consensus to close this without taking it forward. 15:52:54 RESOLUTION: Close this issue. 15:53:59 Topic: Support for Responsive Timed Text tt-reqs#10 15:54:05 Peter: [has to leave] 15:54:13 github: https://github.com/w3c/tt-reqs/issues/10 15:54:45 Nigel: Cyril raised this and I supported it. Does anyone have anything bad to say about it right now? 15:54:51 Pierre: I think this approach is worth a try. 15:55:04 Glenn: My conclusion is requirement 1 is already supported and requirement 2 is problematic. 15:55:15 Pierre: Problematic in the solution or the requirement? 15:55:42 Glenn: I see it as an ask to support event based timing. 15:55:45 Nigel: I don't see that. 15:55:56 Cyril: I am not married to the marker proposal. 15:56:09 .. The idea is to provide not line break opportunities but event based opportunities. 15:56:32 .. It could be a conditional timing hierarchy for a given unit of content. 15:57:20 Pierre: This is a really important topic. I don't know the answer, but if we succeed it will really help the 15:57:28 .. industry so we should give it a shot. 15:57:36 Glenn: One solution is to produce different documents. 15:57:53 Pierre: There are multiple combinatory choices 15:58:18 Glenn: This is also needed for karaoke where we have an algorithm for pushing content into a display 15:58:24 .. region dynamically. 15:58:34 .. You can't reuse IDs so that's off the table. 15:58:57 mike has joined #tt 15:58:58 Pierre: Setting aside the solutions, do you think the requirement is relevant? 15:59:10 .. Looking at the images. 15:59:20 .. Being responsive to those different aspect ratios. 15:59:30 Glenn: I haven't given enough thought but it seems something worth considering. 15:59:39 Andreas: From our side we think it is an important requirement. 15:59:54 .. Making responsive web content is important and it would be good to do the same for TTML. 15:59:59 q+ 16:00:04 ack at 16:00:23 Glenn: It is only the splitting that is an issue. 16:00:26 ack vla 16:00:49 Vlad: I agree it is important to be responsive in this way. I like the way you put it Cyril but the samples 16:01:08 .. don't go beyond line breaks and text size, you don't do it justice, but the requirement is good. 16:01:25 .. Responsive design and typography, i.e. using full scale variability using variable font support, which 16:01:44 .. every browser does with CSS support and we are talking about scaling font from condensed to wide. 16:02:43 RESOLUTION: We will attempt to meet these requirements in 2019. 16:03:05 Topic: Minor enhancements for Japanese subtitles tt-reqs#12 16:03:10 github: https://github.com/w3c/tt-reqs/issues/12 16:03:50 Nigel: If CSS has done this then we should do it. 16:03:58 Cyril: We should work with CSS and adopt what they do. 16:04:08 .. I'm not asking for doing this without CSS support. 16:04:20 .. This is mostly about edge cases not fundamental Japanese language support. 16:04:40 Nigel: So Cyril does that mean you will take the lead with CSS WG to get these defined? 16:04:43 Cyril: I will try! 16:04:59 Glenn: This is the case where a module to define this would be appropriate and can be tracked to a 16:05:20 .. timeline that matches what CSS is doing. We can do things in parallel with modules without having to 16:05:24 .. waterfall it all together. 16:05:46 .. Then we can explore with CSS their interest in solutions, and propose something to them and see how 16:06:07 .. they react to it. I have no strong feeling on whose solution we adopt, the one we came up with or something new. 16:06:24 Nigel: Anyone want to speak against doing this? 16:06:54 RESOLUTION: Proceed with additional Japanese language features in a TTML3 module in close coordination with the CSS WG. 16:07:19 Topic: Support for Karaoke tt-reqs#9 16:07:23 sorry to interrupt but the webex and phone coordinates aren't working for me 16:07:29 github: https://github.com/w3c/tt-reqs/issues/9 16:08:15 s/sorry to interrupt but the webex and phone coordinates aren't working for me// 16:09:23 Nigel: This is closely related to some of the other issues we discussed earlier, including granular timing and transitions. 16:09:44 Cyril: The use cases are quite different. It is not about responsiveness but transition styles, not about 16:09:59 .. changing the layout. We would like to signal the semantics of karaoke separately from the styling. 16:10:17 .. For example ingesting IMSC content with karaoke styling and then we would decide what karaoke means 16:10:29 .. and apply styling ourselves, or in the document. 16:10:34 Present+ Mike 16:11:21 Glenn: Without agreeing with the specific requirements or proposed solutions I'm in favour of moving 16:11:33 .. forward with some kind of requirement for supporting karaoke. I need to digest this a little more and I 16:11:51 .. also want to look at what ARIB-TT did because they defined some support for karaoke that I haven't 16:12:11 .. looked at in detail. It is something to map to a module if possible. 16:13:17 Nigel: I see a lot of overlap between different requirements today, for example the text emphasis style 16:13:34 .. seems to have something in common with the inline image requirement. 16:13:50 Pierre: Emphasis style allows a quoted string so you can have the emphasis be whatever you want. 16:13:55 Cyril: Okay that's a good solution. 16:14:02 s/good/potential good 16:14:26 Glenn: It could conceivably even be an animated glyph because you can use SVG animation in an embedded font. 16:14:41 Cyril: I'm interested in animation between words not within the glyph. 16:15:44 Nigel: Isn't this a completely new layout requirement for animating a moving ball between words? 16:16:01 Vlad: It is and strictly animations are not permitted in SVG glyphs. 16:16:21 Cyril: I am fine with this in a TTML module but what about IMSC, maybe a karaoke profile? 16:16:50 Pierre: One data point supporting getting it into IMSC at some point is that IMF supports karaoke without 16:17:09 .. this key functionality. I suggest doing the TTML3 module first and then if there is industry support 16:17:24 .. adding it into IMSC as a small change. 16:17:50 .. Then if it doesn't have to be part of IMSC by end of 2019 that makes it a lot easier. 16:18:23 Cyril: Instead of IMSC 2019 being published on the same date as TTML3 then we could pipeline them and 16:18:27 .. that would make it easier. 16:18:38 SVG glyph limitations as defined by the OpenType spec: https://docs.microsoft.com/en-us/typography/opentype/spec/svg#svg-documents 16:18:41 Pierre: We said we would try to publish all new specifications by end of 2019 and pick requirements based on that target. 16:19:01 Glenn: To raise the modularisation approach we should be motivated to minimise what we have to do in a TTML3 baseline document 16:19:15 .. so we get it out the door more quickly than the modules we define functionality in, by focusing on the 16:19:31 .. framework for modularisation as the key thing in TTML, then focus in parallel the modules that take 16:19:50 q+ 16:20:03 .. advantage of that framework. Then we decouple to a certain extent getting IMSC to a particular gate. 16:20:19 Pierre: Makes sense to me. If we think we get it done by June in TTML3 then the feature in IMSC by the end 16:20:23 .. of the year is feasible. 16:20:32 Andreas: Is this issue accepted? 16:21:32 PROPOSAL: Take up the karaoke requirements in 2019 16:21:53 Glenn: There are a bunch of requirements, 6 of them, I don't know if I would agree to all those at this time 16:22:01 .. but I think we should move those forward. 16:24:33 RESOLUTION: We will take these requirements forward for our 2019 work. 16:24:54 Topic: Wrap-up 16:25:11 Nigel: Wrapping up very quickly because we're over time. 16:25:34 .. Today we went through all the requirements issues that were open, and made a call on them where we 16:25:55 .. could, and we agreed to create a modularisation framework for TTML to allow us to work on orthogonal 16:26:16 .. functionality in separate Rec track documents. I have the action to draft the TTWG Charter update 16:26:28 .. to grant us permission to do this, which I will do in the next month. 16:27:11 .. We meet same time tomorrow, 0830 Geneva time, and will revisit the Live requirements. 16:27:41 Andreas: If someone could draft timelines for our work that would help. 16:27:49 Nigel: Thierry has that action. 16:27:59 Andreas: We need a plan for the modules work. 16:28:22 Pierre: Could the glue be added to TTML2 for modularisation because it doesn't affect conformance? 16:28:30 Glenn: Let's take that up at a later date. 16:29:39 Cyril: I may not be able to join tomorrow because of the timezone. 16:30:02 Nigel: Thanks everyone. Enjoy your evening, I'll adjourn the meeting now. [adjourns meeting] 16:30:06 rrsagent, make minutes 16:30:06 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 16:55:38 atai has joined #tt 17:01:34 i/testing/Topic: Spoken subtitle tt-reqs#13 17:01:48 i/testing/Nigel: There's been good debate here. The function is in wide use especially in Europe, and we have 17:02:42 scribe+ nigel_ 17:02:47 rrsagent, make minutes 17:02:47 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:04:09 s/scribe+ nigel_// 17:04:17 d/Nigel: There's been good debate here. The function is in wide use especially in Europe, and we have/ 17:04:27 s/Nigel: There's been good debate here. The function is in wide use especially in Europe, and we have/ 17:04:30 rrsagent, make minutes 17:04:30 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:05:03 s|d//|| 17:06:08 s/Nigel: There's been good debate here. The function is in wide use especially in Europe, and we have// 17:06:37 s/Topic: Spoken subtitle tt-reqs#13// 17:06:39 rrsagent, make minutes 17:06:39 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:08:03 i/Nigel: There's been good debate here/Topic: Spoken subtitle tt-reqs#13 17:08:08 rrsagent, make minutes 17:08:08 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:09:16 i/Nigel: There's been good debate here/scribe: nigel_ 17:09:34 i/able to read the translation. Some/scribe: nigel 17:09:36 rrsagent, make minutes 17:09:36 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:10:09 s/+q// 17:10:10 rrsagent, make minutes 17:10:11 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:10:54 s/github-bot, end topic//g 17:10:55 rrsagent, make minutes 17:10:55 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:11:47 s/.. New properties or elements are clearer./Glenn: New properties or elements are clearer. 17:12:09 s/I would like to get to CR by June 1/I would like to get to FPWD by June 1 17:12:17 s|c/CR/FPWD|| 17:12:24 rrsagent, make minutes 17:12:24 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:20:36 s/.. finished checking if we have interoperability/Silvia: finished checking if we have interoperability 17:21:18 s|github-bot: https://github.com/w3c/tt-reqs/issues/4|| 17:21:32 s|nigel, Sorry, I don't understand that command. Try 'help'.|| 17:22:10 s/.. new requirement that would potentially be IMSC 1.2 or IMSC 2, so on this one we should deal with/Pierre: new requirement that would potentially be IMSC 1.2 or IMSC 2, so on this one we should deal with 17:22:42 s/.. new Charter Skynav will object to it formally/Glenn: new Charter Skynav will object to it formally 17:23:02 rrsagent, make minutes 17:23:02 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:25:30 s/nigel, Sorry, I don't understand that command. Try 'help'.// 17:25:32 rrsagent, make minutes 17:25:32 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:26:29 s/s|||// 17:26:30 rrsagent, make minutes 17:26:30 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:26:44 s/nigel, Sorry, I don't understand that command. Try 'help'.// 17:26:45 rrsagent, make minutes 17:26:45 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:27:14 s|s/nigel, Sorry, I don't understand that command. Try 'help'.//|| 17:27:15 rrsagent, make minutes 17:27:15 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 17:27:39 scribeOptions: -final -noEmbedDiagnostics 17:27:41 rrsagent, make minutes 17:27:41 I have made the request to generate https://www.w3.org/2019/01/31-tt-minutes.html nigel 18:40:30 Zakim has left #tt 19:56:01 atai has joined #tt