14:01:48 RRSAgent has joined #tt 14:01:48 logging to http://www.w3.org/2017/04/20-tt-irc 14:01:50 RRSAgent, make logs public 14:01:50 Zakim has joined #tt 14:01:52 Zakim, this will be TTML 14:01:52 ok, trackbot 14:01:53 Meeting: Timed Text Working Group Teleconference 14:01:53 Date: 20 April 2017 14:02:44 mike has joined #tt 14:03:38 Present: Philippe, Mike, Pierre, Nigel 14:03:42 Chair: Nigel 14:03:46 scribe: nigel 14:03:58 Topic: This meeting 14:04:17 Philippe: I will have to leave before the bottom of the hour. 14:04:27 Present+ Glenn 14:05:51 Present+ Andreas 14:06:45 atai has joined #tt 14:07:10 Nigel: For today we have TPAC planning, TTML, IMSC and a new agenda item for HDR in PNG. 14:07:54 Nigel: I have one extra issue for TTML, which is the inline boxes one, as discussed on the reflector. 14:08:17 Mike: I'd like to spend a minute or two on how the normative references are interpreted 14:08:22 .. when there is no assigned version. 14:08:29 Present+ David 14:08:37 s/David/David_Ronca 14:09:00 Andreas: I have an additional proposal, to look at the timeline we made in London 14:09:14 .. regarding TTML2 and IMSC 2 work and see where we are. I think that also affects TPAC. 14:09:39 David_Ronca has joined #tt 14:09:53 Nigel: Thanks, any more points to raise? 14:09:58 group: no more 14:10:24 Topic: TPAC 2017 Advanced Planning 14:10:50 Nigel: Does anyone currently have a preference for meeting on any of the days particularly? 14:11:09 Andreas: I have no preferences but would like to avoid conflicts with other meetings I want to attend. 14:11:28 Nigel: Any groups that we want to avoid clashes with? Or hold joint meetings with? 14:11:50 Andreas: The last 2 times we joined the Web & TV IG. In 2016 it was official, in 2015 it was 14:12:02 .. a Chair's report. I assume it would be useful to try not to clash with that group. 14:12:04 Nigel: Agreed. 14:12:35 Andreas: We have also discussed CSS related issues so we should think about requesting 14:12:37 .. a joint meeting. 14:12:52 Nigel: Yes let us certainly do that, with the scope being to present styling requirements 14:13:00 .. for subtitles and captions that cannot currently be met by CSS. 14:13:44 Nigel: OK I will complete the form asking for any 2 days and avoiding the groups we just mentioned. 14:14:00 .. If anyone has other points to raise on this, or constraints, please let me know. 14:14:43 Nigel: The other thing I need to mention is that if anyone has difficulty attending the meeting 14:14:56 .. in person, perhaps because of travel difficulties, please let me know in case W3C can 14:15:02 .. assist e.g. with remote attendance. 14:15:20 Topic: TTML 14:15:37 s/TTML/TTML (process) 14:18:47 Nigel: Last week we discussed the process, and the Chair was urged to discuss it with the Editor. 14:19:02 .. That happened, and other conversations also. As a result I would like to reiterate that 14:19:10 .. we have a process that we agreed previously, 14:19:18 -> https://github.com/w3c/ttml2/blob/gh-pages/EDITING.md#ttml2-editing-guidelines 14:20:05 Nigel: And we should stick to that. A reminder that as a normal rule aside from minor 14:20:17 .. editorial changes pull requests will be left open for a minimum of 3 days before merging 14:20:28 .. and if anyone wishes to request extra review time then that will normally be granted up 14:20:30 .. to 14 days. 14:20:47 .. As Chair I also would ask that everyone is as flexible as possible in allowing the Group 14:21:03 .. to make progress given that we are past our London-agreed deadline already. 14:21:50 Pierre: What is the policy on pull requests when somebody submits one, in terms of best practice? 14:23:09 Nigel: First of all the Editor has requested a branch naming convention, which is a convenience, but 14:23:13 .. for me not a primary requirement. 14:23:27 .. Secondly if a totally different proposal for an issue is made then it should be in a different 14:23:44 .. branch with a different Pull Request. However if modifications need to be made on a 14:23:55 .. Pull Request they should be made on that request's source branch. 14:25:11 Philippe: Sorry I can't stay longer. Bye everyone [leaves] 14:26:12 Topic: TTML (Prioritisation and assessment relative to planned timeline) 14:26:53 Nigel: In the agenda I noted that we have passed our self-imposed deadline for publishing 14:27:09 .. a WD for WR and that there may be a need to review the priorities of issues and possible 14:27:21 .. drop the axe on some of them now. Andreas, you wanted to raise this also? 14:27:34 Andreas: In London we set a positive schedule, which we have missed, but I do not know 14:27:45 .. where we stand and how far away are we from what we originally planned, and then 14:27:55 .. what is the new realistic deadline and how it can be acheived? 14:28:48 Nigel: OK, that's an important question, thank you. 14:29:02 Pierre: Before we consider deferring issues we should think about the best process for 14:29:14 .. disposing of issues going forward. We should talk about the process for going forward 14:29:57 .. with TTML2. In London we discussed a process, where we went through TTML1 issues 14:30:15 .. and marked them as "discussed and agreed" and those have not yet been fixed. 14:31:23 Nigel: You're asking about the editorial progress in implementing those issues? 14:31:29 Pierre: Yes. 14:31:40 Glenn: As a blanket statement that is not correct. Some of the discussed and agreed issues 14:31:57 .. have been closed, others are effectively done and marked as To close? which I would 14:32:07 .. have closed if we did not wish to wait for consensus before closing an issue. 14:32:21 .. There are a couple of discussed and agreed issues that have had work done but not been 14:32:30 .. updated. So progress is being made, but it is not complete. 14:32:43 .. The list I am working from is the open issues under the TTML2 WR milestone, which 14:33:02 .. is showing 58 open, of which 4 are marked as "to close?" so that could be turned into 14:33:05 .. 54 pretty soon. 14:33:17 Nigel: And where are we up to with those 54? 14:33:30 Glenn: I've been prioritising the Discussed and agreed first. There are some that come from 14:33:52 .. TTML1 changes that are not raised yet, for example issue 221 on TTML1 and Andreas's 14:34:05 .. pull request which I processed further last night. So there are a couple of TTML1 issues 14:34:19 .. that we need to bring in. Otherwise I am making my way through this. There are quite 14:34:31 .. a few that have had some work done that need to be wrapped up, for example around 5 14:34:48 .. issues that pertain to the new annex defining semantics of display extent, which we 14:34:58 .. talked about quite a bit in London, so those can be dealt with by wrapping up that work. 14:35:36 .. I'd say that most of these 54 have had a fair amount of discussion and some may 14:35:47 .. require more technical discussion in the group than others. Maybe a third should be 14:35:54 .. fairly straightforward to wrap up. 14:36:12 Nigel: That would be around 18 being 54/3. 14:37:32 q+ 14:37:53 Nigel: Given that there's a fair amount of effort to do, the obvious thing to me would be 14:38:09 .. to bring in more editorial effort by other group members than the Editor to draft 14:38:13 .. pull requests to resolve issues. 14:38:18 ack atai 14:38:36 Andreas: I understand it is important for some people to reach Recommendation by the end 14:39:13 pal has joined #tt 14:39:25 .. of the year. One way to handle this with so many open issues is to mark some issues 14:39:36 q+ 14:39:43 .. as being less high priority so the TTML2 spec would still be valid if we did not address them. 14:39:47 ack pal 14:40:02 Pierre: Going down one path you hinted at, I've heard folks from Netflix being really keen 14:40:14 .. on completing this work, and Movielabs, and the BBC and perhaps others. I'd be 14:40:25 .. surprised if we couldn't find resources there to help work on editing the document. 14:40:33 .. That's a path that perhaps we should explore. 14:40:51 Glenn: There are two issues to separate: one is generating draft text to incorporate, and 14:41:02 .. the second is doing final editing on that if necessary. We need the former more, which 14:41:19 .. is to generate pull requests to resolve particular issues. I have said on multiple occasions 14:41:25 q+ 14:41:31 .. that I welcome other members generating pull requests to be contributed for inclusion. 14:41:41 .. If other resources are available that's what I'd like to see done. 14:41:43 ack pal 14:43:32 Pierre: I think it needs to be more than that because if the Editor is unable to process all those 14:43:42 .. pull requests then we would be in a similar situation. 14:44:08 Nigel: To be clear, my comment earlier was about one individual both drafting and merging 14:45:09 .. rather than just merging. However it certainly is common practice in W3C to have 14:45:25 .. multiple Editors for a specification and I would encourage that, and Philippe has indicated 14:45:41 .. to me that he would support that. It removes the opportunity for bottlenecks. However 14:46:01 .. I think Glenn has mentioned before that he would like to retain a single view for 14:46:09 .. consistency. 14:47:18 Pierre: If this is something that the group wants then the Chair could ask proponents for 14:47:22 .. more editing help. 14:47:50 Glenn: I should mention that I have cleared my schedule in May to deal with issues. 14:49:19 Pierre: I would recommend that the Chair assigns issues to specific people to dispose of, 14:49:35 .. and separately I recommend raising the issue with proponents regarding resource 14:49:41 .. availability for providing more Editing. 14:50:27 Nigel: It is not clear to me why the Chair needs to assign issues - if proponents are 14:50:48 .. interested in taking on an issue then I suggest they do so, as a first step add a comment 14:50:53 .. to the issue stating the intention to resolve. 14:52:06 q+ 14:53:05 Pierre: There are some open pull requests, for example one on TTML1 raised in February. 14:53:09 ack atai 14:53:26 Andreas: The TTML1 one was requested in London within two weeks otherwise Glenn would 14:53:41 .. propose something else. I tried to fix it as soon as possible but then it seemed it was 14:53:52 .. not needed that urgently. It's not a big issue for me. In terms of getting more people 14:54:04 .. involved it would be more motivating for people if we deal with pull requests in time. 14:54:16 Glenn: Thank you for providing that input very quickly. It was then waiting for me to do 14:54:28 .. final editing. So in terms of final editing I have been giving it some thought and finally 14:54:41 .. made the changes I thought were necessary yesterday. There are also some comments 14:55:40 .. on an earlier commit. 14:56:12 .. One of the issues I have is that issues seem to need full group discussion before closing. 14:56:22 Nigel: In fact that can be done on the issue. 14:56:31 .. It does not need the group to discuss it in a meeting. 14:57:16 .. By the way we do not have a group policy for how long pull requests should take to 14:57:26 .. process, but it seems reasonable to me that it should be days or a small number of weeks 14:57:35 .. and that "months" is too long. 14:59:37 David_Ronca: Looking at the WR, there are comments that first it was March, and now it 14:59:52 .. looks like it will be June, and I don't see any strong way that we can ensure we will 15:00:02 .. publish the WR in June. We are beginning to get the perception that we will never get 15:00:13 .. there. We have a lot of time and money invested in this project, and nobody can move 15:00:24 .. until we make progress. I don't feel like we're leaving this meeting today having made 15:00:29 .. progress. 15:00:39 Nigel: What progress are you hoping for? 15:00:49 David_Ronca: Perhaps some agreement on how we can meet WR in June. 15:01:13 .. I agree that we need to delegate issues out. We need to start making some hard decisions 15:01:22 .. about what's in or what's out. If there's some way that we can contribute more to try to 15:01:28 .. get these resolved then I would. 15:04:51 Nigel: Working backwards that means that we need to have pull requests open or merged 15:05:02 .. for all issues to be met in the WR by the end of May so that the group has enough time 15:05:16 .. to review and get to consensus on publishing those resolutions as a WD. If there are 15:05:29 .. remaining issues open at that point without pull requests then we would need to make 15:05:33 .. hard decisions at that point. 15:05:54 Pierre: Issues raised externally will not go away, they will still need to be addressed. 15:06:13 Nigel: That's true, however we do have an opportunity to resolve external issues between 15:06:37 .. WD and CR. 15:06:48 Glenn: The disposition can be a deferral. 15:07:23 David_Ronca: I would hate to begin work on an issue and find someone else is doing it. 15:07:43 Nigel: Well you could assign yourself to it, and also add a comment so if anyone else is 15:07:48 .. working on it then they can mention that. 15:08:04 Glenn: Also I would suggest asking me in case I've already put some thinking into it. 15:08:22 Pierre: That's inefficient.If you've already begun to think about it you should assign the issue to yourself. 15:08:28 s/t.I/t. I 15:08:39 David_Ronca: I would agree with that - if we can assign resource to make a sprint on this 15:09:04 .. then I would like to see issues assigned, and non-assigned issues need to be assigned 15:09:06 .. to somebody. 15:09:39 .. I'm actually willing to try to get my team to make some contributions to push through 15:09:53 .. this. I want to do it efficiently. I would appreciate if every issue being worked on has an 15:09:58 .. assignee. Is that a reasonable request? 15:10:09 Glenn: Yes, they should at least do a first attempt to read the comments. I will go through 15:10:10 +1 15:10:23 .. and see if I have given anything significant thought and not documented then I may 15:10:29 .. assign it to myself. 15:10:40 David_Ronca: That would make it much easier because then I can filter the unassigned issues. 15:11:17 Glenn: I need to do a pass through and review the current status. 15:11:28 .. There's also a label "Request help" so it might be useful to make more use of that label. 15:11:45 David_Ronca: Glenn please could you assign the ones you are working on to yourself? 15:11:50 Glenn: Sure, that seems reasonable. 15:12:01 .. I'll do it this week or next week. 15:13:08 Nigel: Okay, that seems like good progress, so we have a way to identify what needs 15:13:17 atai has left #tt 15:13:19 .. working on and when something is already being worked on, some offers of more 15:13:35 .. effort, and some offline discussions to have. Thanks. 15:13:42 David_Ronca: I have to drop off now. 15:13:49 Andreas: Me too. [leaves] 15:13:57 s/now./now. [leaves] 15:14:01 Topic: TTML (issues) 15:14:08 Glenn: I'd like to raise #292. 15:14:30 -> https://github.com/w3c/ttml2/issues/292 Update note regarding ISOBMFF and DASH. 15:14:54 Glenn: This is an issue pointed out by Mike on email recently, with reference to DASH, 15:15:34 .. ISO BMFF, CMAF and so forth. I committed this directly since it is an informative change. 15:15:40 .. If that is acceptable I would like to close it. 15:15:55 Mike: It's editorial, not a big deal, thanks. 15:16:26 Nigel: I'm happy with it too. 15:16:59 .. I've closed. 15:17:14 Nigel: Apologies Mike we haven't been able to get around to your question about 15:17:28 .. unversioned normative references, and now we have no staff on the call to assist. 15:17:39 Mike: That's okay, it can wait until we have Thierry of Philippe on the call. 15:17:52 .. I noticed that some references have versions or dates and some don't and wonder how 15:17:55 .. we deal with those. 15:18:06 Glenn: For tracking and transparency purposes we should probably open an issue on this 15:18:16 .. post it as a question, adding the "question" label. 15:18:22 Mike: Sure I'll do that. 15:18:36 .. It may result in changes of some sort but I'm happy to start with a question. 15:19:07 s/I've closed./I've closed that issue. 15:19:35 Nigel: Can we raise the inline boxes issue? 15:19:52 -> https://github.com/w3c/csswg-drafts/issues/814 [css-inline] Define the content area of inline boxes 15:20:37 Nigel: Am I correct in understanding that the proposal on the issue is essentially the same 15:20:57 .. semantic that we want with a different syntax? 15:21:07 Glenn: They have not yet proposed any semantic. They would also have to deal with the 15:21:21 .. fact that height and width do not currently apply to non-replaced inline boxes. There's 15:21:42 .. nothing in CSS so far that alters that. The second thing is if there are keywords that would 15:21:54 .. satisfy our needs. I think we should not make our work dependent on their process. 15:22:45 Nigel: My proposal is that we define the semantic that we want and add it to the CSS issue. 15:23:04 Glenn: We can do that. First we need to agree what we want to achieve. We need a concrete 15:23:17 .. proposal on our side. We have two action items, first as agreed in London to change 15:23:31 .. the semantics of bpd and ipd so it does not trigger the inline block semantic and second 15:23:44 .. to define a way using bpd or a keyword to mean what we want it to mean. When we have 15:23:54 .. that at least in an ED we can provide a reference to that for the CSS folk. 15:24:14 Nigel: Those are both things you have been working on Glenn - where are we up to on them? 15:24:38 Glenn: Yes. 15:24:46 -> https://github.com/w3c/ttml2/issues/150 Ways to make span background height be lineHeight 15:25:00 Glenn: I will assign that to myself and create a new issue to track the agreement to add 15:25:12 .. a new keyword to the display property called inlineBlock and change the semantics in a 15:25:20 .. few places that had automatically triggered that behaviour. 15:25:37 .. Since it changes something we've had for a while some implementations like TTPE will 15:25:41 .. need to be changed accordingly. 15:26:42 Nigel: I've assigned 150 to you Glenn. This also affects issues 146 and 163. 15:27:10 Nigel: In my view the separation of inline block semantics is the resolution to #146. 15:27:22 -> https://github.com/w3c/ttml2/issues/146 Inline block semantics impacts text wrapping 15:27:27 Glenn: You're right, yes. 15:27:41 Nigel: I see you're already assigned to #146. 15:30:29 Nigel: On the point about HDR I see that I have just received an email from a colleague 15:30:42 .. giving me the go-ahead to make a BBC submission to add to the annex about HDR an 15:31:07 .. alternate way to convert sRGB using hybrid-log gamma. I will do that shortly. 15:31:12 Glenn: Is this a replacement text? 15:31:20 Nigel: No it's an additional method. 15:31:47 -> https://github.com/w3c/ttml2/issues/233 Add support for compositing a TTML2 document onto HDR video 15:32:56 Pierre: The reason for removing the to close? label was documented in the minutes. 15:33:33 .. I will create a PR to address the current comments. 15:33:50 Nigel: I see that we are both assigned to this. I will create a PR for the HLG way of doing it. 15:34:01 Glenn: We have not discussed the name yet in the group. I think the simpler name is better. 15:34:59 Nigel: Pierre and I have already made clear our preference for the more specific name. 15:35:20 Glenn: I do not think we will need to use luminance for anything else. 15:35:33 Mike: Luminance is a term that goes way beyond what we mean here so I would prefer that 15:35:45 .. it be qualified in some manner. The original proposal was a little verbose but we need 15:35:49 .. something more than just luminance. 15:36:07 Glenn: I'm happy with luminanceGain. 15:37:41 s/I'm happy with/How about 15:37:44 s/n./.? 15:37:56 Pierre: I'm happy with luminanceGain, I don't think you are Nigel? 15:38:38 Nigel: My test question is: can it be used in any other capacity than for PQ HDR? 15:40:06 Pierre: It is an absolute gain. [some discussion] 15:40:17 .. To get to a PQ encoded image you need absolute luminance, which you get to with this 15:40:19 .. metadata. 15:40:43 Nigel: Is it the only way it can be used? 15:41:15 Pierre: It can be used to create an HDR image for other encodings than PQ. 15:41:34 .. It does not specify anything only specific to PQ. The value can be used for other purposes. 15:44:22 Pierre: The end result of applying this is that you end up with an XYZ value with absolute 15:44:31 .. luminance that you can then do what you want with. 15:44:55 .. Fundamentally the issue is that sRGB is limited to 0-80 cd/m. There are schemes that 15:45:11 .. can use a broader dynamic range. The goal is to be able to produce images that can be 15:45:26 .. used in any number of schemes, one of which is PQ but conceivably others. 15:46:06 Nigel: And my understanding is that XYZ is essentially canonical, so if we define 15:46:22 .. luminanceGain to be the thing you use to get to a canonical format then I'm happy with that. 15:46:35 Pierre: Yes it is the thing that gets you to absolute luminance values. 15:47:23 Nigel: Ok then let's go with luminanceGain 15:47:44 .. If there is some unexpected further problem with that then we can deal with that later. 15:47:52 Pierre: I will make a PR to deal with that and the other comments. 15:47:57 Glenn: Ok that's good. 15:49:33 Nigel: I added comment https://github.com/w3c/ttml2/issues/233#issuecomment-295787705 15:50:07 Nigel: What can we look at next? I think we have done enough in the offline discussion to 15:50:14 .. deal with the smpte discontinuous issue? 15:50:26 -> https://github.com/w3c/ttml2/issues/161 15:50:33 Glenn: I'll do a PR for that. 15:50:35 Nigel: Thank you! 15:51:02 .. I have assigned it to you Glenn. 15:52:17 Nigel: Did we get anywhere on whitespace handling? 15:52:26 -> https://github.com/w3c/ttml1/issues/235 Ambiguity regarding tab (U+0009) processing in significant whitespace. 15:52:46 Glenn: I sent an email to Steve Zilles because I could not resolve this by looking at the XSL 15:53:07 .. specification. CSS now says that a significant tab gets mapped to spaces - I would like 15:53:18 .. to avoid using those semantics if possible. My preference is that if a tab is significant 15:53:34 .. then either treat it as zero space or exactly one space but I need other input. 15:53:53 Pierre: The XSL spec is really clear - tabs are preserved but it does not say what a tab is! 15:54:01 .. Where do you see the ambiguity in the XSL spec? 15:54:55 Glenn: Two issues: one is what do the xml:space semantics mean with a tab? ... 15:55:13 Nigel: I just want to step in here - the explanation is in the issue. Pierre is there a problem with that? 15:55:26 Pierre: Yes, and I will add that to the issue. The issue is that CSS changed. To my mind you 15:55:36 .. should just not put tabs in TTML documents! It doesn't say what happens. 15:55:46 Pierre: A solution, regardless, is to say authors should not put tabs in their documents. 15:56:00 Glenn: That's not an adequate solution because they appear all the time. For xml:space="default" 15:56:16 .. we need to define whether there is a case where a tab may appear or if it is always 15:56:35 .. normalised to space. I think I convinced myself that tab is mapped to space in this case. 15:57:03 Pierre: I'll take an action item to comment on the thread. Regardless I think tabs should not be present in the document. 15:57:15 Nigel: The question is not if it should be allowed in a document but to define what to do with 15:57:21 .. it if it is present. 15:57:48 Glenn: If it is mapped to space then we do not need to deal with it, but if it is preserved then 15:58:00 .. it falls into the reduced infoset and it needs some presentation semantics. We have some 15:58:17 .. options, to treat it as 0 space, 1 space or like CSS does, some multiple of spaces. 15:58:59 Nigel: What gave rise to this issue is that if xml:space="default" some tabs are preserved. 15:59:15 Glenn: Only if they are the first character of an element or the first character after a new line. 15:59:33 .. That was the question I posted, maybe I'll take the text of my question to Steve and Tony 15:59:41 .. and paste it onto the comment so that people can see what I was askign. 15:59:46 s/gn/ng 16:00:30 Nigel: We're out of time, thanks everyone. [adjourns meeting] 16:00:33 rrsagent, make minutes 16:00:33 I have made the request to generate http://www.w3.org/2017/04/20-tt-minutes.html nigel 16:47:27 s/issue 221/#221 16:50:55 s/to the issue stating the intention to resolve./to the issue stating the intention to resolve. In general in W3C we work on the natural selection model where things that people are interested in get resolved. Assigning issues proactively will prevent other interested parties from contributing, so I am not in favour of doing that. 16:53:36 s/150/#150 16:53:43 s/ 146/ #146 16:53:57 s/ 163/ #163 16:54:07 s/issues #146/#146 16:54:31 Zakim has left #tt 16:54:33 s/I see that we are both/I see that Pierre and I are 16:54:57 s/luminanceGai.?/luminanceGain? 16:56:22 s|https://github.com/w3c/ttml2/issues/161|https://github.com/w3c/ttml2/issues/161 No restriction on time expression for smpte discontinuous mode 16:57:18 rrsagent, make minutes 16:57:18 I have made the request to generate http://www.w3.org/2017/04/20-tt-minutes.html nigel 16:59:35 ScribeOptions: -final -noEmbedDiagnostics 16:59:36 rrsagent, make minutes 16:59:36 I have made the request to generate http://www.w3.org/2017/04/20-tt-minutes.html nigel 17:04:58 Regrets: Thierry 17:04:59 rrsagent, make minutes 17:04:59 I have made the request to generate http://www.w3.org/2017/04/20-tt-minutes.html nigel