14:00:30 RRSAgent has joined #tt 14:00:30 logging to http://www.w3.org/2017/10/12-tt-irc 14:00:32 RRSAgent, make logs public 14:00:32 Zakim has joined #tt 14:00:34 Meeting: Timed Text Working Group Teleconference 14:00:34 Date: 12 October 2017 14:01:17 scribe: nigel 14:01:19 Present: Nigel 14:01:22 Regrets: None 14:01:25 Chair: Nigel 14:01:50 Present+ Pierre 14:01:53 cyril has joined #tt 14:02:24 Present+ Thierry 14:02:33 mike has joined #tt 14:03:12 Present+ Glenn 14:03:31 Present+ Mike 14:04:02 Present+ Cyril 14:04:20 Topic: This meeting 14:04:56 Nigel: Today, I don't think we have anything to discuss with TPAC today; 14:05:22 .. I'd like to start running the TTML2 Wide Reviews to see if we have any easy dispositions. 14:05:42 .. And we agreed last week to discuss publication of FPWD of IMSCvNext 14:06:06 .. And we have had some other issues raised this week on TTML1/2. 14:06:38 Mike: Request to cover backward compatibility issue in TTML 14:06:41 Nigel: Ok 14:07:57 .. I'm not expecting David to join to discuss WebVTT review today. 14:08:03 Thierry: I've had no confirmation. 14:08:15 Nigel: In that case I think we have a full agenda. 14:08:30 atai2 has joined #tt 14:08:32 Nigel: Any other specific points to cover? 14:08:40 Group: nothing else. 14:10:55 Topic: processor backwards compatibility #458 14:11:00 github: https://github.com/w3c/ttml2/issues/458 14:11:21 Glenn: This may be a duplicate of #442 - anyway they are related. 14:11:39 Present+ David_Ronca 14:12:22 Mike: It's hard to summarise from the issue - lots of opinions, not necessarily harmonious. 14:13:11 .. It boils down to how we make IMSC vNext reference TTML2 or TTML1, since we need 14:13:26 .. a safety net for presentation processor conformance for IMSC 1.0.1. 14:13:44 .. These things are all intertwined. Fundamentally we started out with what we are doing 14:13:48 .. in IMSC v1.1. 14:15:51 Nigel: Pierre recently made the comment that the presentation processor differences 14:16:26 .. between TTML1 and TTML2 are already proposed for TTML1 Third Edition. If we do that 14:16:37 .. would it address the problem for IMSC or just move the problem somewhere else? 14:17:07 Glenn: I don't think we can add features to TTML1 to resolve all the differences. 14:17:08 pal has joined #tt 14:17:21 Pierre: Trying to keep things simple, the first step is to determine if we all think that the 14:17:34 .. goal of having TTML1 and TTML2 be consistent on shared features is a good idea. Then 14:17:39 .. we can figure out how to make that happen. 14:18:01 Glenn: I agree with that as a default scenario. We could probably add a statement to the current 14:18:14 .. section on backward compatibility that says its an objective to achieve that modulo 14:18:20 .. explicit variations or exceptions. 14:18:30 Pierre: Anyone think it's a bad idea to have that as a goal? 14:18:41 Mike: No, and that's where I thought we ended up last week. 14:19:06 Andreas: I think it's important to make it mandatory to state this objective in the spec. 14:19:21 .. People will look for normative statements, otherwise it won't help much. 14:20:12 Glenn: It's different stating the objective to making a mandatory requirement on processors. 14:20:17 .. We should separate those. 14:20:58 David has joined #tt 14:22:29 Nigel: I think there is a problem if we let edge cases drive specs, and I particularly don't 14:22:57 .. want us to be held back by previous specifications and be unable to make improvements 14:23:03 .. if we find them. 14:23:40 Cyril: Are we allowing for specific signalling of TTML2 behaviour? 14:23:51 Pierre: This is only for features that TTML1 and TTML2 have in common. 14:25:57 Pierre: The question is if the high level goal is for parity of processing, as a high level 14:26:06 .. principle, then we can come to the details later. 14:26:23 Nigel: My understanding is this is driven by a desire for identical presentation processor 14:26:35 .. output, so the details become important. I don't think that the general guiding principle 14:26:43 .. is controversial, and it's easy to agree with. 14:27:02 Glenn: There are layers that affect every feature - it's not simple than just talking about 14:27:08 .. individual style features. 14:27:19 Pierre: It would be bad if TTML1 and TTML2 compelled implementations to end up with 14:27:41 .. a different computed font size on an element due to differing inheritance rules. 14:27:53 Glenn: I recall lineHeight and ongoing discussion of this in TTML2 vs TTML1. 14:28:02 Pierre: That's my point - these should be aligned. 14:28:19 .. Again, it's the normative statements that it's important to make consistent. 14:28:41 Glenn: We made some explicit decisions about lineHeight="normal" - we shouldn't go back 14:28:44 .. to those decisoins. 14:28:52 s/oi/io 14:29:04 Pierre: I'm just asking about the general principle. 14:29:28 Andreas: The rendered outcome of a document only using TTML1 vocabulary should 14:29:39 .. generate the same outcome for TTML1 and TTML2 processors - this should be the goal 14:29:48 .. of our activity. It should be mandatory for processors. 14:30:02 Glenn: I certainly would not agree to that statement, in its entirety at least. 14:30:23 David_Ronca: From my perspective the primary objective for TTML2 is a robust spec that 14:30:36 .. will carry us into the future. Where its possible to be TTML1 compatible we should be 14:30:50 .. but we should not preserve ambiguous or poorly defined features in TTML1. 14:31:03 Andreas: That's a core question - how much is backward compatibility needed. 14:32:47 Nigel: We have a mechanism via the TTML profile registry for systems that use it to request 14:33:04 .. a specific processor type, and we should use the flexibility that gives us. 14:33:24 Glenn: We have never had a normative requirement to have different implementations 14:33:35 .. produce the same presentation as a general statement. If you throw out a lot of other 14:33:42 q+ 14:33:46 .. variation axes, then you might say that modulo those variations it should be close. 14:33:57 ack atai2 14:34:11 Andreas: Following the discussions, maybe there are different business requirements here. 14:34:41 .. For our side, backward compatibility is a first priority. We are in the middle of uptake 14:34:52 .. and adoption of the spec so it's important that current implementation is not blocked by 14:35:07 .. a message that TTML2 is coming and may change it. That gives the message "wait for TTML2". 14:35:21 .. At least we want to avoid that and keep TTML adoption ongoing including IMSC1 adoption. 14:35:42 Nigel: Good point - my statement earlier was that in agreement with David_Ronca I think 14:35:57 .. it is a stronger objective to produce a future facing spec than a backward compatible one. 14:36:18 David_Ronca: Compare to video coders. We have to be able to make fixes and correctness 14:36:30 .. needs to outweigh compatibility. TTML2 implementations can still be TTML1 implementations. 14:36:44 .. It's just like encoders can still make AVC or HEVC. We have to be careful. I don't know 14:36:58 .. if there are specific cases where we need stability of features, but if TTML2 gets it right 14:37:05 .. and TTML1 gets it wrong then TTML2 should prevail. 14:37:11 Mike: Is there an example of this? 14:37:23 Pierre: I'm not aware of such a thing, and ironically many of those bugs were discovered 14:37:39 .. while implementing TTML1, so most have been logged as a bug on TTML1 and fixed in TTML2. 14:37:55 .. So my technical opinion is that the probability that we can align the two is very high 14:38:01 .. via TTML1 Third Edition. 14:38:35 Glenn: I would not agree - there are specific things like displayAspectRatio that are ambiguous 14:38:39 .. in TTML1 but fixed in TTML2. 14:38:51 Pierre: That ambiguity would have to remain in TTML1. 14:38:59 .. The common features can be aligned. 14:39:13 Glenn: If it's simply a matter of fixing prose (even normative) then I think we can back-fill 14:39:19 .. ambiguities that don't require new featuers. 14:39:24 s/ers/res 14:39:33 Cyril: Why not deprecate ambiguous TTML1 features? 14:39:45 Pierre: Some of the ambiguities are in the core layout and styling algorithms. So it's not 14:39:57 .. deprecating a features, just correcting an ambiguity in TTML1. 14:40:15 Cyril: If it's ambiguous in TTML1 then noone can interoperably implement it in TTML1. 14:40:29 Pierre: This is core, basic things like lineHeight style inheritance. 14:40:47 Cyril: Two choices: either it has been demonstrated interoperably, or it has not, in which case 14:40:52 .. let's deprecate the feature. 14:41:05 Pierre: You can't do that - you can't deprecate style inheritance. 14:41:13 Cyril: Has it been demonstrated interoperably? 14:41:25 Pierre: TTPE and IMSC.js implemented it the same way. 14:41:33 Cyril: Why not fix the spec to reflect it? 14:41:37 Pierre: Exactly. 14:41:53 Glenn: We cannot deprecate features in TTML1. There is no requirement for rendering 14:42:03 .. interoperability, though it may have been a goal for some implementers. 14:42:17 Pierre: I agree with you Cyril, we should make it work consistently. 14:42:55 .. My suggestion is to fix it in TTML1 Third Edition. We could conceive of other ways, but 14:43:02 .. that seems like a straightforward way of doing it. 14:44:16 Nigel: I think if we can achieve consistency by retro-fitting to TTML1 Third Edition that makes 14:44:33 .. it a lot easier, but does that work for IMSC 1.0.1 which references 2nd Edition? Would 14:45:42 .. that resolve the original IMSC compatibility issues? Would it make TTML2 processors 14:45:53 .. process say IMSC1 documents in an acceptable way? 14:46:16 Pierre: We have a lot of resolutions in TTML1 GitHub issues reflecting TTML2 fixes, and 14:46:22 .. we should capture those in a TTML1 Third Edition. 14:46:38 .. The next step is to update IMSC 1.0.1, to give those organisations that care the opportunity 14:46:49 .. to update their implementations to match the updated specs. 14:47:13 .. W3C can't compel implementers to reference a particular version of a spec. 14:48:21 Nigel: I have no problem with that - making TTML1 Third Edition aligned with TTML2 14:48:36 .. so that TTML2 represents clean feature additions. 14:48:53 Pierre: I would like to go back to the general principle. 14:49:20 Glenn: If it's too general I might not be able to agree. 14:49:43 https://github.com/w3c/ttml2/issues/458#issuecomment-336022891 14:49:50 Pierre: I proposed the text in the issue above. 14:50:06 Glenn: I need to contemplate that language. 14:51:03 .. When you say "features that the specs share" that doesn't address my point about layers. 14:51:25 Pierre: "given a document that contains only TTML1 syntax, a processor was compelled by the TTML2 specification to process it differently than it would have been compelled by the TTML1 specification." 14:51:35 Glenn: I don't agree with that, the way it is expressed. 14:52:02 .. A clarification question: in some of my commentary on the issues I have pointed out 14:52:16 .. that an implementor may implement a processor that adheres to some subset of TTML1 or TTML2, 14:52:32 .. so if you're objective as stated could be used as a mandate to require a TTML2 implementation 14:52:45 .. to operate in a bug-for-bug compatible way with TTML1? 14:53:24 Pierre: W3C doesn't compel implementors to do anything. Given a TTML1-only syntax document, 14:53:37 .. the processors should not yield a different outcome on those features that they have in common. 14:54:22 Glenn: I could accept a general objective - as soon as you start hinting at touching the 14:54:27 .. conformance section the answer is no. 14:54:38 Pierre: So do you agree on the objective of making TTMl1 and TTML2 consistent on the 14:54:42 .. features they share? 14:54:48 Glenn: Yes, and we can add that language. 14:55:19 Andreas: Yes, that should be a clear objective. It is also important to say in the text that 14:55:36 .. a TTML1 document containing only TTML1 syntax, then this applies, but that if TTML2 14:55:46 .. syntax is present then the outcome may be different. 14:56:04 David_Ronca: What's a document that shares TTML1 and TTML2? 14:56:16 Pierre: No, the document would contain only features in common, i.e. TTML1 syntax. 14:56:43 Andreas: [has to drop off] 14:57:08 Cyril: Maybe a different perspective to the question: in terms of implementation, how do 14:57:18 .. you translate your design goal? To minimise the overhead of implementing both TTML1 14:57:37 .. and TTML2, or further, to reuse exactly the TTML1 implementation for a TTML2 renderer. 14:57:50 Pierre: That's not what I had in mind, though it would be awesome if one could do the latter. 14:58:19 Cyril: In the worst case scenario, if I have an implementation that switches based on 14:58:25 .. document type then it won't make any difference. 14:58:38 Pierre: The goal is to avoid completely different tests, code paths, authoring tools etc. We're 14:58:55 .. trying to make it easier for people with a limited amount of resource. 15:02:04 SUMMARY: General agreement that there should be compatibility where possible, and that this may be achieved in practice by publishing TTML1 Third Edition being made compatible with TTML2 where practical. 15:03:49 Cyril: A practical question: did this begin with a question about the processing rules for tts:disparity present in an IMSC 1.0.1 document? 15:04:17 Glenn: It's not simply a matter of the document using TTML1 features only, so we need to handle 15:04:22 .. more generally which rules to follow. 15:04:37 Mike: It is complicated, but we need to be clear, so if e.g. ATSC adopts one or two TTML2 15:04:51 .. features into TTML1-based IMSC 1.0.1 we need to be sure that the act of doing that 15:05:02 .. doesn't cause things to behave differently. 15:05:15 Cyril: We could avoid this issue by back-porting the feature to TTML1. 15:05:56 .. Apparently it doesn't require any other changes in TTML2. 15:06:44 Pierre: Conceivably we could create IMSC 1.0.2 to solve disparity. 15:06:48 Glenn: We cannot add it to TTML1. 15:06:53 Cyril: OK that's fine. 15:07:13 .. Are there any other features coming from TTML2 that may land in IMSC? 15:07:21 Mike: ATSC may adopt luminanceGain. 15:07:29 Cyril: That would be a path to at least solve that issue practically. 15:07:55 Pierre: We could follow the same path as fillLineGap in IMSC 1.0.1, by creating 1.0.2 15:08:04 Mike: If that solves the problem it'd be fine. 15:08:31 Nigel: This feels like the moment to mention that factoring out the style attributes into a 15:08:47 .. separate specification altogether might be quite helpful, separate from the other spec 15:08:48 .. semantics. 15:09:43 Mike: Someone needs to draft the text that reflects this discussion. 15:09:50 Nigel: For the TTML2 spec? 15:10:17 Mike: I think that's the target. 15:10:48 Nigel: Glenn? 15:10:56 Glenn: I'll draft something and send it to the list for discussion. 15:11:12 Nigel: I'm happy to look at that and try to make sure it reflects this discussion. 15:11:25 Mike: [needs to drop off the call] 15:11:58 Topic: IMSC 15:15:41 action-507? 15:15:41 action-507 -- Nigel Megitt to Add imsc vnext repo to agenda, board, github-bot etc -- due 2017-10-05 -- PENDINGREVIEW 15:15:41 http://www.w3.org/AudioVideo/TT/tracker/actions/507 15:15:52 Nigel: That's all done, and the TT board has been updated, so closing. 15:15:56 close action-507 15:15:56 Closed action-507. 15:16:48 Nigel: Now what about the FPWD of IMSC 1.1? 15:16:51 Pierre: It's ready to go. 15:17:00 Thierry: There are a couple of issues to discuss offline. 15:17:13 Pierre: The pub-rules checker said it was okay. 15:17:24 Thierry: I'll send you what I've found, and then request publication for the 17th. 15:18:05 https://github.com/w3c/imsc/blob/IMSC1.1/imsc1/spec/ttml-ww-profiles.html 15:18:22 https://rawgit.com/w3c/imsc/IMSC1.1/imsc1/spec/ttml-ww-profiles.html 15:18:51 Nigel: Last week we made the proposal to publish this. Any objections? 15:19:14 Cyril: No objection, but I did raise a few issues on the document, mostly trying to clarify 15:19:26 .. the relationship between this IMSC version and the previous one. It's important that 15:19:38 .. people understand with simple communications what are the differences. 15:20:05 .. Pierre has responded to the issues. 15:21:05 RESOLUTION: TTWG agrees to publish FPWD of IMSC 1.1 15:21:19 action-509? 15:21:19 action-509 -- Pierre-Anthony Lemieux to Propose liaison text for the imsc 1.1 fpwd -- due 2017-10-12 -- OPEN 15:21:19 http://www.w3.org/AudioVideo/TT/tracker/actions/509 15:22:00 -> https://lists.w3.org/Archives/Public/public-tt/2017Oct/0087.html Proposed liaison text re: IMSC 1.1 FPWD 15:22:27 Thierry: Who do we want to send this to? Should we use the same list as for the wide review? 15:22:34 Pierre: Same as the IMSC 1.0.1 WR I would say. 15:22:41 Thierry: Okay I will dig into that and come up with the list. 15:23:05 Pierre: There's an MPEG meeting the week after next so it's important to send this soon. 15:23:16 Thierry: I will update the drafts and send the final one after publication. 15:23:29 Nigel: I notice there's a deadline for comments - why is that? 15:23:38 Pierre: It's arbitrary, just seems like a good idea. 15:24:19 Nigel: This isn't a call for wide review so I don't think it's a good idea to set a deadline for 15:24:30 .. comments but it would be good to indicate the proposed timeline. 15:24:39 Cyril: +1 15:24:46 Pierre: What about Wide Review in January? 15:24:49 NIgel: Why not! 15:24:53 s/NI/Ni 15:25:45 Pierre: We could just notify that we've started work and invite contributions. 15:25:47 Nigel: Perfect. 15:26:21 Cyril: Yes, what about just dropping the "by 13 December 2017" 15:26:23 Nigel: +1 15:26:29 Pierre: I'll fix the "submits" typo too. 15:26:42 Nigel: I'll take the action to update this and respond. 15:26:47 Pierre: OK great. 15:27:34 https://github.com/w3c/imsc/issues/263 15:27:46 Topic: itts:fillLineGap is unclear about what it is filling between exactly #263 15:27:52 github: https://github.com/w3c/imsc/issues/263 15:28:29 Pierre: Were you happy with the renders Nigel? 15:28:32 Nigel: Yes I think so. 15:28:48 Pierre: My proposal is not to make any normative changes in IMSC 1.0.1 but to add 15:29:02 .. informative text and those examples, as well as maximising the chances of using 15:29:11 .. roll-up harmoniously with fillLineGap, would resolve this issue. 15:29:37 .. It was not completely intuitive to me, but since fillLineGap didn't exist before, just saying 15:29:41 .. how to use it should work. 15:30:23 Cyril: Nigel you said line areas can be generated without `
`s? 15:30:29 Nigel: Yes, line areas can be generated by line wrapping. 15:30:42 Pierre: I agree with your interpretation Nigel, by the way. 15:31:17 SUMMARY: @palemieux to attempt to exemplify this without substantive changes. 15:32:27 Topic: What fillLineGap does/ affects #254 15:32:33 github: https://github.com/w3c/imsc/issues/254 15:33:02 Pierre: I didn't understand this, but maybe the new examples for #263 will help. 15:33:04 Nigel: Maybe! 15:33:09 .. I didn't understand either. 15:33:23 Pierre: If we get to a point ready to move past CR we will need to ping @r12a. 15:33:47 Cyril: A side comment - for rubys in TTML2 would fillLineGap apply? 15:33:59 Glenn: The presentation of the ruby is an annotation on a line area effectively so it would 15:34:10 .. be simply covered by the line gap as well. The height of the line gap would be predicated 15:34:22 .. on the height of the line area, which would in turn be predicated on any annotations and 15:34:27 .. the space that they need. 15:35:42 Cyril: Would the line gap between the ruby and the base text be filled by fillLineGap? 15:36:05 Glenn: Yes it's part of the line area already. It's a bit like the dot on an i. 15:37:34 Topic: Should UTF-8 'as specified in' point to the Encoding spec? #253 15:37:40 github: https://github.com/w3c/imsc/issues/253 15:38:07 Nigel: I see you asked @r12a a question, @palemieux, so I think we're just waiting for that. 15:38:10 Pierre: That's right. 15:38:44 Topic: TTML2 Wide Review Issues 15:39:33 Topic: SMPTE backgroundImage annotation #460 15:39:38 github: https://github.com/w3c/ttml2/issues/460 15:41:29 Nigel: [describes call from yesterday that generated this issue] 15:41:38 Glenn: If we're talking about an informative note I don't see any issue there. 15:41:40 Nigel: Yes that's it. 15:41:54 Glenn: I'd probably say something like it's motivated by smpte:backgroundImage and 15:42:00 .. extended to make it more compatible with ... whatever. 15:42:05 Pierre: It's more than that. 15:42:08 Glenn: It is, yes. 15:42:24 Pierre: I think what Nigel said is it's important to state equivalence. 15:42:37 Glenn: It goes beyond smpte:backgroundImage 15:42:51 Pierre: But there's a mapping from smpte:backgroundImage. 15:42:54 Glenn: Yes that would be fine. 15:43:08 Nigel: Yes that's a fair representation of the proposal. 15:44:13 .. I think we need to say something like "The semantics of the smpte:backgroundImage 15:44:25 .. attribute may be achieved by [whatever the equivalent is]". 15:44:47 Glenn: Recall that there are two mechanisms in TTML2 - backgroundImage and image, 15:44:58 .. serving different purposes, one for content, the other for background styling. 15:45:13 .. In effect backgroundImage in SMPTE was ambiguous about whether it was for content 15:45:22 .. or styling - I suspect both, but mainly for content. 15:45:35 Nigel: I think it is clear it's for content. 15:45:43 Pierre: It is intended to be content, that's established. 15:46:04 Glenn: It's not stated in the SMPTE spec. 15:46:17 Nigel: I thought you weren't supposed to have text in an element with backgroundImage, 15:46:26 .. which settles it for me - worth checking though. 15:49:56 Topic: [HTML5] reference should be informative. #461 15:50:00 github: https://github.com/w3c/ttml2/issues/461 15:50:40 RESOLUTION: HTML5 needs to be made an informative reference in TTML2. 15:50:53 Topic: [SSML] reference should be informative. #462 15:50:58 github: https://github.com/w3c/ttml2/issues/462 15:51:05 RESOLUTION: SSML needs to be made an informative reference in TTML2. 15:51:20 Topic: [WEBAUDIO] reference should be informative. #463 15:51:34 github: https://github.com/w3c/ttml2/issues/463 15:51:50 Nigel: The normative status of WebAudio may change in the future but we can make it 15:51:54 .. informative for now I guess. 15:52:01 RESOLUTION: WEBAUDIO needs to be made an informative reference in TTML2. 15:52:13 Topic: [XML 1.1] reference should be removed. #464 15:52:20 github: https://github.com/w3c/ttml2/issues/464 15:52:38 RESOLUTION: No use is made of the XML 1.1 reference so remove it. 15:52:55 Topic: Examples in section S use an unusual tts:displayAlign setting #459 15:53:01 github: https://github.com/w3c/ttml2/issues/459 15:53:14 Glenn: That's a simple fix. 15:53:27 Nigel: Yes, I commented in support of this on the TTML1 issue too. 15:53:44 RESOLUTION: Add tts:displayAlign="after" to examples. 15:54:00 Topic: Examples in section O use an unusual tts:displayAlign setting #254 15:54:06 github: https://github.com/w3c/ttml1/issues/254 15:54:09 RESOLUTION: Add tts:displayAlign="after" to examples. 15:54:21 Topic: Question about #background-color vs #backgroundColor. #455 15:54:30 github: https://github.com/w3c/ttml2/issues/455 15:54:54 Glenn: I can see that the two feature designators could be confusing. The background-color 15:55:11 .. was added in TTML2. Pierre has pointed out that backgroundColor includes the same 15:55:23 .. things as background-color pulled in, namely the block, inline and region versions. I think 15:55:35 .. the resolution is to remove background-color and possibly add some text to #backgroundColor 15:55:47 .. to say that it includes those as well, informatively. 15:56:36 Pierre: In TTML1 did #backgroundColor include those three things? 15:56:44 Glenn: Yes by implication but not explicitly. 15:56:59 Pierre: That was my conclusion too. In that case I would file an issue in TTML1 to make 15:57:02 .. that explicitly. 15:57:16 Glenn: I would do this as a note in TTML2 and TTML1. 15:57:44 RESOLUTION: Remove #background-color and add an informative note that it includes block, inline and region and raise an issue to do the same on TTML1 Third Edition. 15:58:21 Topic: Examples in section S use an unusual tts:displayAlign setting #459 15:58:28 github: https://github.com/w3c/ttml2/issues/459 15:59:10 Pierre: It would be good to change the examples also to put the timing on spans rather than p elements, in S.2 15:59:12 Nigel: +1 15:59:40 Pierre: That might avoid people adding fillLineGap in a copy of the example and not understanding 15:59:43 .. why it doesn't work! 15:59:46 Nigel: Agreed. 16:01:01 RESOLUTION: In S.2 Modify the example to put the timing on span elements and separate lines with `
` inside those timed spans. 16:02:02 Topic: Meeting round-up 16:02:25 Glenn: Next week I'd like to talk about TTML2 issues #437, #438, #439 and maybe #435 16:02:38 .. and possibly a couple of others that are editorial fixes. 16:02:48 Nigel: Yes, I'd like to tackle some TTML issues next week. 16:03:12 Glenn: We could also discuss #428 and #429 which are about activeArea and fillLineGap 16:03:18 .. making them the same as IMSC 1.0.1 16:03:39 .. Then the other question in my mind is what we do with namespaces... 16:04:06 Pierre: That's my proposal. I don't disagree that it's unfortunate. In the future we can 16:04:23 .. maybe add new things directly into TTML2. 16:04:38 Glenn: Another possibility is in 1.0.2 change to tts: namespace? 16:05:04 Pierre: It would break implementations that look for the existing namespace. 16:05:18 .. This is less than ideal, but it will cause the least amount of pain overall for implementers 16:05:20 .. and users. 16:05:31 Glenn: I'm not suggesting that we have a reference from TTML2 to IMSC, but that we 16:05:41 .. incorporate the syntax identically and the prose to the extent that we can. 16:05:45 Pierre: I agree with that proposal. 16:06:02 Glenn: Nigel where are we with #427? 16:06:26 Nigel: I've made a lot of progress - the umbrella issue is #406, and #427 lays the structural 16:06:30 .. groundwork, and that's done. 16:10:02 Glenn: I would prefer to make the table row say "Derivation:". 16:17:32 Nigel: Okay, when you see it, it might make sense. I'll remove the "(informative)" though. 16:17:39 Nigel: Thanks everyone [meeting adjourned] 16:17:44 rrsagent, make minutes 16:17:44 I have made the request to generate http://www.w3.org/2017/10/12-tt-minutes.html nigel 16:34:57 s/if you're objective as stated/if your objective as stated 16:40:20 s/groundwork, and that's done/groundwork, and that's done in the issue-0406- branch. 16:40:28 rrsagent, make minutes 16:40:28 I have made the request to generate http://www.w3.org/2017/10/12-tt-minutes.html nigel 16:44:07 ScribeOptions: -final -noEmbedDiagnostics 16:44:09 rrsagent, make minutes 16:44:09 I have made the request to generate http://www.w3.org/2017/10/12-tt-minutes.html nigel 16:53:12 Zakim has left #tt