14:00:11 RRSAgent has joined #tt 14:00:11 logging to http://www.w3.org/2017/10/26-tt-irc 14:00:13 RRSAgent, make logs public 14:00:13 Zakim has joined #tt 14:00:15 Meeting: Timed Text Working Group Teleconference 14:00:15 Date: 26 October 2017 14:00:42 Present: Nigel 14:00:44 Regrets: Andreas 14:00:47 Chair: Nigel 14:00:49 scribe: nigel 14:01:30 Present+ Cyril 14:02:03 Present+ Glenn 14:03:56 cyril has joined #tt 14:06:38 Regrets+ Thierry 14:07:08 Topic: This meeting 14:09:06 Nigel: Today we have: TPAC planning, TTML1 and TTML2 (not much to discuss?), 14:09:30 .. IMSC Pull Requests and TTML2 Pull Requests. As in recent meetings I haven't had 14:09:44 .. confirmation that anyone will join to discuss WebVTT but if they do then we may be able 14:09:49 .. to cover that. 14:10:23 Glenn: [will need to leave after 1 hour] 14:10:50 Cyril: I'd like Glenn's opinion on last week's discussion about compatibility issues between 14:10:54 .. TTML1 and TTML2. 14:10:56 Nigel: Ok. 14:11:45 Topic: TPAC 2017 Advanced planning 14:11:54 Cyril: Have we heard anything more from CSS WG? 14:12:13 Nigel: I have not, no, I will check in with the Chairs, Alan and Rossen to see if they have 14:12:15 .. any suggestions. 14:12:35 Nigel: I wanted to mention that since our Charter expires at the end of March 2018, I've 14:12:49 .. added it to the TPAC agenda topic list, since we may want to begin thinking about the 14:12:53 .. next steps. 14:13:53 .. Following up on the discussion we had about the "demo" session, Pierre and I have a 14:13:59 .. plan of action, and I've added some text to: 14:14:20 -> https://www.w3.org/wiki/index.php?title=TPAC/2017/SessionIdeas#TTML_and_IMSC_rendering_in_Javascript_with_CSS_styling TPAC Demo session proposal 14:15:03 Present+ David_Ronca 14:16:36 .. If other people want to come along that's fine, otherwise Pierre and I will be there to 14:16:47 .. explain about TTML rendering in browsers with Javascript, and the challenges of mapping 14:16:55 David has joined #tt 14:16:58 .. to CSS, including some of the TTML2 features. 14:17:24 .. It will give us a chance to gauge interest. I'm not sure exactly what the format is, if we 14:17:38 .. are in a single room or if we will all be gathered together in one big space. 14:18:57 Topic: TTML1 and TTML2 compatibility in practice 14:19:12 Cyril: Not much to discuss, Glenn, did you have time to look at it and review what was 14:19:17 .. discussed last week about the document? 14:19:34 Glenn: I've given it a first review and thank you for doing the work - it's very useful. It will 14:19:45 .. help provide another set of objective considerations to look into if we have issues. 14:19:58 .. From my first pass, I didn't see anything there that was overly surprising or alarming, 14:20:31 .. which was good, so that's a good first step at least. Nothing popped out at me right away. 14:20:43 .. It has always been my intention to try to minimise any substantive issue that would cause 14:20:59 .. problems for a TTML2 processor to process a TTML compliant document, so I think I've 14:21:12 .. succeeded to a certain extent. Some of the details over time have changed the TTML2 14:21:25 .. spec and it's probably a good opportunity to go back and see if there's been any inadvertent 14:21:57 https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejXbYBuL4CRRrbmEZRbwZpg/edit#heading=h.p3blw6xu90rj 14:22:05 .. movement away from that goal. Of all the things you looked at, it seems like there were 14:22:12 .. one or two orange or red blocks? 14:22:14 glenn has joined #tt 14:22:27 Cyril: There was ttp:pixelAspectRatio, tts:direction, tts:overflow and the computed style set processing. 14:22:31 https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejXbYBuL4CRRrbmEZRbwZpg/edit#heading=h.p3blw6xu90rj 14:23:13 Glenn: On pixelAspectRatio we have tried to nail down the issue of aspect ratios more carefully, 14:23:26 .. particularly by introducing display aspect ratio, which is different. Right now the way I 14:23:44 .. see it is that the TTML1 processor has more freedom to interpret display aspect ratio and 14:23:55 .. the coordinate space of the TTML document, so if anything what we have done is to try 14:24:06 .. to make it less ambiguous. That's one of the areas of change that I think Nigel commented 14:24:19 .. on recently when he said that if there are errors or ambiguities in TTML1 that we need 14:24:31 .. to fix then that may present us with some inevitable change and is something we are 14:24:45 .. assuming may occur. I guess we have to keep our eyes on how they may cause issues. 14:24:56 .. In this case my feeling is that existing implementations, being less constrained by the spec, 14:25:08 .. will produce potentially a greater variety of results than they would otherwise so authors 14:25:18 .. cannot rely on a consistent treatment of ambiguous things in TTML1. 14:25:32 Cyril: That's my understanding, that in most cases the TTML2 changes make things more precise 14:25:36 .. and reduce the variability. 14:25:40 Glenn: That's right. 14:25:58 .. Moving onto tts:direction, I recall that in XSL 1.1 this language already appeared, or something 14:26:11 .. very close to it, and we had not documented it or pointed it out in TTML. In a sense we 14:26:24 .. were incomplete with regard to our intention to adhere to XSL semantics. This is another 14:26:35 .. case where we tried to nail down something we had a precedent for in XSL. 14:26:44 Cyril: So this can probably be back-ported to TTML1 Third Ed.? 14:26:52 Glenn: Yes, as resolving an ambiguity. 14:27:06 Cyril: I'll take the action to make sure there is an issue on TTML1 Third Edition for this. 14:27:17 Glenn: I don't think there is one, so that's a good idea. 14:28:04 Cyril: Last week I had the action to propose changes as part of ttml2#458 for the compatibility 14:28:18 .. section of TTML2. My idea was to write the text in a similar way to how I wrote it at the 14:28:47 .. beginning of this document, would you agree with a sentence like this in §3.4.2 or TTML2? 14:29:21 .. "TTML2 is designed in such a way that a TTML1 document (not containing any TTML2 feature) would be rendered by a TTML2 presentation processor in an acceptable way according to TTML1. This includes all variations allowed per TTML1. " 14:29:33 Glenn: Someone may question "in an acceptable way" but looks good on the surface. 14:29:47 Cyril: I'll put the text in the issue so we can fine-tune it. I plan to put it in §3.4.2. 14:29:54 Glenn: Right, that sounds like a good home for it. 14:30:14 .. I'm sensitive that Mike has continued to insist on language about an exact same rendering, 14:30:17 .. which is problematic. 14:30:32 Cyril: I tried to avoid that by talking about being acceptable within the variations allowed in TTML1. 14:30:38 Glenn: That's one way to handle that. 14:31:01 Cyril: There's one part of that section about TTML1 document instances being intended to 14:31:15 .. be conformant TTML2 documents. I don't know why the wording "is intended" is present? 14:31:19 .. What would be the difference? 14:31:37 Glenn: The section is non-normative and I was trying to capture the intentions of the spec 14:31:48 .. writer and the group for objectives for the specification as opposed to mandating or 14:31:58 .. requiring a state of affairs normatively. 14:32:17 Cyril: The "is intended" is a bit weak - I would prefer to say "TTML2 is designed such that 14:32:27 .. a conforming TTML1 document is a conforming TTML2 document". 14:32:35 Glenn: I think we can do that. We should at least aim for it. 14:32:44 Cyril: I'll comment on the issue with the two proposed changes. 14:32:57 Glenn: Thanks. I appreciate issues where exact spec text material is provided as a starting point. 14:36:59 Topic: Definition of tts:fillLineGap does not match itts:fillLineGap as specified in IMSC 1.0.1. #429 14:37:06 github: https://github.com/w3c/ttml2/issues/429 14:38:08 Nigel: The last comment on this is from me, saying we need practical proposals to address the needs of 14:38:14 .. the various constituents. 14:38:31 Glenn: We already don't support, say, smpte:backgroundImage, so there's a precedent for 14:39:13 .. not supporting fillLineGap seems no different. 14:39:29 Nigel: That's confusing - not putting smpte:backgroundImage in TTML2 doesn't mean it 14:39:36 .. cannot be in a profile. 14:39:42 Glenn: That's right. 14:39:56 David_Ronca: We've been advocating that IMSC vNext is a subset of TTML2, but there are 14:40:16 .. two ways to get to it - either make sure that there's a TTML2 equivalent feature for everything, 14:40:29 .. or by bringing IMSC namespace attributes into TTML2. We prefer the former. 14:40:49 .. We'd like to address the features in TTML2 not by pulling in IMSC namespace. 14:41:55 Nigel: Reminder that we agreed to look at each case individually last week, and that we 14:41:58 .. should do that at TPAC. 14:42:01 Glenn: Makes sense to me. 14:42:13 David_Ronca: We should do that, at TPAC. 14:42:31 Nigel: For fillLineGap specifically I'd like more detailed proposals. 14:43:56 .. We have tts:fillLineGap in TTML2 and itts:fillLineGap and they have different wording, so 14:44:09 .. they may have different semantics. The goal is probably to align the semantics, and then 14:44:26 .. for IMSC vNext we need to think about how to handle this if both are permitted, for all 14:44:29 .. constituents. 14:45:25 Topic: Add equivalent CSS properties to style attributes #406 14:45:31 github: https://github.com/w3c/ttml2/issues/406 14:45:39 pal has joined #tt 14:45:55 Nigel: Glenn, have you been able to look at this? 14:46:00 Glenn: I've not completed looking at it. 14:46:29 Nigel: Primarily I'm interested in incorrect mappings, and secondarily on formatting - I'm 14:46:46 .. not especially happy with how it's turned out but I don't have a better suggestion. 14:47:16 -> https://github.com/w3c/ttml2/pull/470 TTML2 Pull Request #470 14:47:35 Topic: Create CSS mapping for tts:fontShear based on CSS skew #471 14:47:41 github: https://github.com/w3c/ttml2/issues/471 14:47:48 Nigel: I haven't made a change for this yet. 14:48:39 .. Cyril please could you confirm my reading of this and the proposed mapping? 14:48:44 Cyril: I will confirm, but I think you're right. 14:50:15 Topic: Allow detection of the EBU-TT-D content profile. #467 14:50:21 github: https://github.com/w3c/ttml2/issues/467 14:50:27 Nigel: To discuss the pull request: 14:50:44 -> https://github.com/w3c/ttml2/pull/468 Add document proceessing context override semantics for effective con… #468 14:51:16 Nigel: There's one easy fix here about an element being called an attribute, and a typo. 14:51:26 Glenn: I'll get those in and maybe we can wrap that one up. 14:51:44 .. Pierre, if you have any additional comments on this please say so, in the thread. 14:51:51 Present+ Pierre 14:52:11 Pierre: The proof will be when we see how IMSC 1.1 uses this, in terms of how the global 14:52:14 .. override works. 14:53:05 .. A global override like is suggested here will work for IMSC. When we walk through the 14:53:16 .. revamped IMSC 1.1 profile resolution section, which is the first user of this TTML2 14:53:29 .. functionality, we'll see if there are any issues. In the meantime I think this pull request 14:53:39 .. addressed the major issue, which is there used to be no way to provide an external 14:53:45 .. input to the process, so that's been fixed. 14:54:00 Glenn: It already did support the document interchange context providing a value if there 14:54:16 .. was no other value than that chosen so far. You had explicitly asked that it pertained 14:54:25 .. to the document processing context as opposed to the document interchange context. 14:54:28 Pierre: That's right. 14:54:41 Glenn: I took that to mean you wanted a way for the processor to look inside the document 14:54:54 .. and make a determination based on the document content or on the entity that's controlling 14:54:59 .. the application. 14:55:11 Pierre: Yes but there's also an issue with the document interchange context, that it comes 14:55:20 .. after everything else, only if everything else failed. 14:55:32 Glenn: That's right, that particular mechanism did not provide an override path, which is why 14:55:42 .. I ended up combining the original request along with an override. 14:55:55 Pierre: Exactly, so right now the new language supports that. 14:55:59 .. Which is fine. 14:56:06 .. We'll try with IMSC 1.1 and see if it works. 14:56:26 SUMMARY: Modulo the minor text edits required, this is good to merge. 14:56:49 Topic: contentProfiles and processorProfiles delimiters possibly ambiguous #474 14:56:56 github: https://github.com/w3c/ttml2/issues/474 14:58:35 Nigel: (summarises last comment on issue) 14:58:50 Glenn: I thought about that - we have some syntax sections like a content value syntax section, 14:59:02 .. where for example is described. I was thinking to have a uri reference 14:59:13 .. subsection added to that to be a sibling with the other items in the content value syntax 14:59:24 .. section, and that we could provide the common language there, and everywhere else we 14:59:44 .. could refer to that syntactic non-terminal without having to repeat the language everywhere. 14:59:47 Nigel: Sounds great to me. 14:59:55 Glenn: Sounds like I can go ahead to craft something in that direction. 14:59:58 Nigel: Yes please. 15:00:26 .. Did you have any thoughts about RFC3986 and percent encoding? 15:00:39 Glenn: I was surprised about this because I had not thought that spaces were permitted in URIs. 15:00:53 .. Where it cautions about the technical possibility of whitespace it is referring to the lexical space, 15:01:07 .. which is not the literal space of the document encoding so some processing has already 15:01:18 .. occurred to put it into the lexical space form. The other thing I noticed was it did not 15:01:35 .. define a canonical lexical space for the URL primitive type, whereas it does for everything else. 15:01:51 .. If it had defined one then I would have expected to see something there dealing with this situation. 15:02:03 .. The point is that percent encoding or decoding would have already occurred between the 15:02:20 .. document literal encoding and the lexical space, but the space would not be in the document. 15:02:32 .. If you combine that with the other XLink reference my conclusion was that in the document 15:02:46 .. you would not see a space, so it is not a problem for parsing. But it does raise the question 15:03:03 .. of if we expect the percent encoded text to be decoded before going into the abstract 15:03:16 .. information set. Since we define everything with reference to the reduced infoset I think 15:03:30 .. we need to say it must still be percent encoded in the infoset. 15:03:37 s/infoset/reduced infoset 15:05:29 Nigel: I agree - percent encoding and decoding is not idempotent so we need to be clear 15:05:44 .. about exactly what should be expected so that the encoding and decoding are done 15:05:47 .. the correct number of times. 15:06:01 Glenn: Yes, and cautionary avoidance of doubt notes are a good idea, and this new section 15:06:11 .. would be the right place for it, so I'll go ahead and do that in a pull request. 15:06:53 SUMMARY: @skynavga to propose a pull request refactoring `` references into the content value syntax section and including a cautionary note about percent encoding. 15:10:47 Topic: Updated profile signaling and resolution to match TTML2 semantics #267 15:10:55 Nigel: I'd like to step through this, but maybe not now. 15:11:22 Pierre: There's still time. It's using the override feature from TTML2. 15:11:31 Nigel: Is it dependent on the TTML2 pull request we discussed earlier? 15:11:36 Pierre: Yes. 15:12:28 Glenn: Isn't there a danger of rewriting or paraphrasing the TTML2 profile resolution semantics? 15:12:33 Pierre: The goal is just to use that. 15:12:49 Glenn: I may have misunderstood in reading between the lines. 15:13:01 Pierre: It says "the profile semantics of TTML2 apply" and then explains how you deal with 15:13:10 .. say, ebuttm:conformsToStandard. 15:13:14 Glenn: That sounds reasonable. 15:13:19 Pierre: It's supposed to be easier! 15:13:38 https://rawgit.com/w3c/imsc/dda2f98b3f3fb817ef482fdb498f298971ce64c3/imsc1/spec/ttml-ww-profiles.html 15:14:05 Nigel: I think what I just realised is that in reading this we have to follow it against not just 15:14:30 .. TTML2 but actually the open pull request on TTML2! 15:14:38 Pierre: Look at §5.4 and §7.8 on the above rawgit link. 15:15:21 Nigel: What does it mean to say that a processor profile is a subset of another processor profile? 15:15:40 Pierre: It means that it's a collection of featuers. 15:15:49 Glenn: It might be useful to say "strict" subset. 15:15:56 Pierre: Literally it's a mathematical subset. 15:16:03 .. of a collection of features. 15:17:10 Nigel: Why didn't you use "superset" vs "subset"? I think it would be more helpful to indicate 15:17:25 .. to adopters that if they have, say, a Text Profile processor then it can be used to process 15:17:36 .. those subset profiles, or can be claimed to be a processor of them. 15:17:48 Pierre: If that works better for you, then fine, it means the same thing. 15:18:08 Nigel: I think it's a pyschological thing - more helpful to describe in positive terms than negative ones. 15:18:40 .. I will have a look and make some other comments. 15:19:41 Topic: Other IMSC issues 15:19:52 Pierre: I've started to indicate which IMSC issues are blocked by TTML2 issues. Some are 15:20:17 .. super boring but cannot be fixed until TTML2 is fixed, for example ttml2#455 that blocks imsc#255. 15:20:23 Glenn: Have you applied a label? 15:20:33 Pierre: I've applied "blocked" on the IMSC repo. 15:20:54 -> https://github.com/w3c/imsc/issues?q=is%3Aopen+is%3Aissue+label%3Ablocked Blocked IMSC issues 15:21:20 Glenn: I think we discussed this and agreed what to do. I should be able to take care of this ASAP. 15:21:26 .. I will enhance its priority. 15:21:58 s/discussed this/discussed #background-color 15:22:26 Pierre: There's also the profile signaling one imsc#261 dependent on ttml2#435. 15:22:54 Nigel: Thanks, that's very useful Pierre. 15:23:33 Glenn: Question - you say that imsc#267 does not require ttp:version... 15:23:46 Pierre: Because IMSC 1.1 requires contentProfiles to be present, ttp:version is never used. 15:24:07 .. There's never an ambiguity that's resolved by the presence of ttp:version, so given the 15:24:24 .. rich semantics we have with ttp:contentProfiles and ttp:processorProfiles I'm concerned 15:24:43 .. that we don't need ttp:version. You could just require that ttp:version or ttp:processorProfiles be present. 15:24:57 Glenn: One of the other main reasons in my mind that ttp:version is useful is to signal to 15:25:10 .. the processor that it is going to require, say, support for ttp:contentProfiles. Right now, 15:25:22 .. if you use that and want to make it the source of any inferences about processor profiles, 15:25:36 .. if the TTML2 processor happened not to support contentProfiles but only processorProfiles 15:25:54 .. then it might not even look for contentProfiles whereas if you say ttp:version="2" that's 15:26:13 .. an implicit statement to tell the processor to pay attention to contentProfiles. 15:26:25 Pierre: The same could be said for a processor that did not support ttp:version. If ttp:version 15:26:37 .. goes away and contentProfiles and processorProfiles are the way they are signalled then 15:26:47 .. it would be dumb for processors not to implement them. 15:27:06 Glenn: It depends what you think you'll get for supporting say contentProfiles. 15:27:33 Pierre: If I'm an author and I want to communicate explicitly to the processor what processor 15:27:44 .. profile is required then I can do that with the designator and that's more expressive 15:27:49 .. and explicit than ttp:version. 15:28:18 Glenn: Yes, in TTML1 we did not require support for ttp:profile, and that optionality was used by EBU-TT. 15:28:37 Pierre: This is greatly improved in TTML2 so maybe we don't need ttp:version. I'm questioning 15:28:49 .. if it is a good idea to have the switches based on the value of ttp:version given the goal 15:29:08 .. to be seamless with TTML1. If we get rid of ttp:version we can maybe get rid of all ambiguity. 15:29:21 Glenn: I'll take a fresh look at it with that in mind. 15:29:40 Pierre: Given the community's experience with TTML1 maybe we should require signalling 15:29:53 .. of the processor profile. Now we can do it there's no excuse not to do it! 15:30:04 Glenn: I agree. 15:30:26 .. I also need to review the code in TTP to see where ttp:version is used. 15:30:41 Pierre: Yes, that goes to the heart of Cyril's work - to resolve if there are spec issues or code issues. 15:30:46 Glenn: OK. 15:30:54 Topic: Meeting close 15:31:04 Everyone: needs to step out/fall asleep. 15:31:15 Nigel: [Hurriedly adjourns meeting] Thanks everyone! 15:31:34 rrsagent, make minutes 15:31:34 I have made the request to generate http://www.w3.org/2017/10/26-tt-minutes.html nigel 15:42:16 s/.. If other people want to come along/Nigel: If other people want to come along 15:43:18 s|https://docs.google.com/document/d/1Ri7RBBsbIK9SRxA1KsHRejXbYBuL4CRRrbmEZRbwZpg/edit#heading=h.p3blw6xu90rj|| 15:49:06 s/featuers/features 15:50:16 rrsagent, make minutes 15:50:16 I have made the request to generate http://www.w3.org/2017/10/26-tt-minutes.html nigel 15:51:03 scribeOptions: -final -noEmbedDiagnostics 15:51:04 rrsagent, make minutes 15:51:04 I have made the request to generate http://www.w3.org/2017/10/26-tt-minutes.html nigel 17:14:42 Zakim has left #tt