13:59:35 RRSAgent has joined #tt 13:59:35 logging to https://www.w3.org/2018/05/17-tt-irc 13:59:37 RRSAgent, make logs public 13:59:37 Zakim has joined #tt 13:59:39 Meeting: Timed Text Working Group Teleconference 13:59:39 Date: 17 May 2018 13:59:56 Log: https://www.w3.org/2018/05/17-tt-irc 14:01:02 Present: Nigel 14:01:04 Chair: Nigel 14:01:06 scribe: nigel 14:01:09 Regrets: Thierry 14:01:15 Topic: This Meeting 14:02:48 cyril has joined #tt 14:03:01 Present+ Cyril, Glenn 14:05:03 Nigel: Today, I don't think we have anything to discuss for Charter, I do need to quickly 14:05:39 .. cover TPAC, then I expect the main part of the meeting to be taken up by the TTML2 14:05:43 .. issues marked as agenda. 14:07:02 .. Any other business, or particular topics to cover other than those TTML2 agenda issues? 14:08:26 Cyril: No 14:08:29 Glenn: No 14:08:38 Pierre: [silence - getting coffee?] 14:08:41 Andreas: No 14:08:45 Nigel: Great, let's get going. 14:08:57 Topic: TPAC 2018 14:09:11 Nigel: The draft schedule has been published, as linked on the agenda: 14:09:16 atai2 has joined #tt 14:09:20 -> https://www.w3.org/2018/10/TPAC/schedule.html Draft TPAC 2018 schedule 14:09:43 Nigel: This has us meeting on Monday and Tuesday, and also has the CSS WG and Media & Entertainment IG 14:09:51 .. meeting on Monday (CSS WG also on Tuesday). 14:10:05 .. The AD CG has time on the Thursday also. 14:10:25 .. My question to you guys is do we want to request a change to the schedule? 14:10:41 Andreas: I definitely think we should request a change in the agenda. The M&E especially 14:10:54 .. has important stakeholders of TTML and so on, and a really good opportunity to discuss 14:11:07 .. TTML specific issues, and as a representative of a broadcast organisation I plan to join 14:11:15 .. the complete meeting of the M&E IG. 14:11:41 Pierre: The fact that it is at the same time as CSS WG is a good thing because it guarantees 14:11:58 .. that CSS folk will be there so we can ask for an hour joint meeting and have reduced 14:12:05 q+ 14:12:09 .. likelihood that we will not be able to get them to join. 14:12:27 .. M&E IG is a different matter. 14:12:41 Nigel: I've also been talking to my colleague Chris Needham who is one of the chairs of 14:12:49 .. the M&E IG about them moving potentially. 14:13:03 Andreas: My impression of CSS WG is that they have more than enough to discuss in their 14:13:21 .. two days, so it may be easier to schedule a joint meeting if we do it on another day. 14:13:33 .. The attendance we had last time in the joint session was sufficient to bring in the major points. 14:14:11 Nigel: I think what I'm hearing is we want to avoid a clash with M&E and to arrange a joint 14:14:22 .. meeting with CSS WG however that is most conveniently achieved. 14:14:32 .. The next question is about our flexibility. 14:15:27 .. Could we for example ask to meet on Tuesday and Friday? 14:15:34 Pierre: I could not be present for an entire week at TPAC. 14:15:57 Nigel: Implying Mon/Tue or Thu/Fri? 14:16:03 Pierre: Yes, with a preference for Mon/Tue 14:16:18 Nigel: Any other constraints on us moving the meeting dates? 14:16:32 Andreas: No, I should be available on Mon,Tue, Thu and Fri. 14:16:48 Nigel: Okay if there are no other views that's enough for me to take back. 14:17:18 Topic: TTML2 items labelled as Agenda 14:17:31 Nigel: We have 15 open items labelled as agenda in ttml2: 14:17:39 -> https://github.com/w3c/ttml2/labels/agenda TTML2 agenda items 14:18:39 Topic: Rename and refactor module subsections. ttml2#591 14:18:47 github: https://github.com/w3c/ttml2/issues/591 14:20:35 Glenn: I don't think we need to do this. 14:21:18 Nigel: I see that it's about moving sections around so that common text does not need 14:21:22 .. to be duplicated. 14:21:35 Glenn: This would cause specref links to lose contextual information. 14:23:06 Nigel: The second part of the issue is that §10.2.1 should apply to the audio attribute 14:23:14 .. vocabulary whereas it currently looks like it does not. 14:23:46 Glenn: This will make the ToC deeper and cause a wide scale renumbering which would 14:24:00 .. invalidate existing references from other specs like IMSC 1.1. I've been trying to maintain 14:24:13 .. section numbering referential integrity. Of course we've had to add new numbers in the 14:24:27 .. 10.2 section so those did get renumbered somewhat. I can see the logic of putting those 14:24:49 .. together. It seems like the only reason to do this is to allow 10.2.1 to apply to both. 14:25:37 Nigel: The audio attribute section does not refer to 10.2.1 and it is scoped out by the 14:25:43 .. section structure. This is the problem. 14:27:27 Glenn: [thinks] What about §10.2.1 is tts-specific? 14:27:54 Nigel: 10.2.x includes the style attribute and everything in tts namespace, 14:28:01 .. whereas 10.3 includes tta namespace. 14:28:06 Glenn: This is editorial only. 14:28:17 Nigel: Are you sure there's nothing substantive implied by the sectioning? 14:28:25 Glenn: Yes, there's nothing substantive. 14:28:28 pal has joined #tt 14:28:39 .. I could put a note in the prologue for section 10 at the end describing why we have a 14:28:52 .. separate section for audio style properties and that these generic style features apply 14:29:00 .. there as well. I don't think there's a problem to solve here. 14:29:36 Nigel: Why do we have 10.3 at all? Why not just run them into §10.2? 14:29:51 Glenn: We could do that, but they would all apply at the top of the list before the tts: 14:30:09 .. attributes, using alphabetical ordering. 14:30:20 Cyril: Since this is editorial can we resolve this in CR2 if we need to? 14:31:57 Nigel: If we can solve it now quickly that would be good. We're doing this now. 14:32:01 .. Any other ideas? 14:32:13 Glenn: Moving the tta: attributes into 10.2 would work 14:32:16 Nigel: Works for me. 14:32:19 Pierre: I don't object. 14:32:41 RESOLUTION: Move the tta: namespace style attributes into §10.2 14:32:45 github-bot, end topic 14:33:12 Topic: Generic processor conformance too strict. ttml2#673 14:33:19 github: https://github.com/w3c/ttml2/issues/673 14:34:44 Nigel: The summary of this is that it is reasonable to have a content profile prohibit use 14:34:53 .. of features that are mandatory for generic processor conformance. 14:35:03 Glenn: I don't think we can make them optional because they're mandatory in TTML1. 14:37:38 .. We have another issue that's related, about making profile-version-2 optional: #683 14:39:12 .. In pull #755 I proposed some language in the claims section that allows for conformance 14:39:24 .. without supporting the mandated features. I think that applies in this context too. 14:39:34 Nigel: Yes, I see that. 14:39:45 Glenn: You're saying you might have a profile that doesn't support things that seem to be 14:39:57 .. mandated by the official minimum profiles, which is not unreasonable and has been done, 14:40:09 .. for example EBU in excluding the profile features. So your additional comment will be 14:40:14 .. dealt with by pull #755. 14:41:14 .. Basically a processor can be a ttml processor but cannot claim conformance as defined 14:41:24 .. by the conformance clauses. 14:43:07 .. It can claim generic conformance but not one of the two special ones. 14:44:11 Nigel: But §3.2.1 bullet 4 requires support for everything listed as M in §E.2. 14:45:32 Glenn: That doesn't mandate support for e.g. #profile. 14:45:49 Nigel: The way I read it is does, because step 4 must be satisfied, and doesn't refer to 14:46:08 .. any profiles, just the specification, and it clearly relates to things listed as M in §E.2, which 14:46:15 .. includes `#profile`. 14:46:28 Glenn: I see what you mean. It's possible that the note is wrong in the context of such a 14:46:40 .. content profile not requiring support for everything listed as mandatory. 14:47:01 Nigel: Good, we're on the same page in terms of the issue at this point. 14:47:19 Glenn: Either you have to implement everything even if use is prohibited by a profile, or 14:47:35 .. we somehow relax that language to permit the creation of an implementation that doesn't 14:48:16 .. require support for all those mandatory features. 14:48:19 Nigel: Yes 14:48:36 Glenn: An option is to have a lower case ttml processor conformance state that does not 14:48:54 .. include Generic Processor Conformance. 14:49:14 .. Back in TTML1 days we had a huge discussion about minimally required features. The 14:49:28 .. first chink in that was when EBU-TT was created. Just a historical fact. 14:49:34 .. Now with IMSC we seem to be following the same path. 14:49:45 .. It looks like we'll need some more thinking on this. 14:50:21 SUMMARY: Issue discussed and mutual understanding improved, more thought needed. 14:50:55 Topic: Move processor conformance out of #validation ttml2#689 14:51:01 github: https://github.com/w3c/ttml2/issues/689 14:51:29 Glenn: This is for Pierre who has asked additional questions on this. 14:52:06 .. [summarises comments on the thread] Pierre, do you still think there's a problem? 14:53:19 Nigel: We can't hear from @palemieux right now, will have to come back to this one. 14:53:40 Topic: The #extent-measure designation includes the value auto. ttml2#690 14:53:48 github: https://github.com/w3c/ttml2/issues/690 14:54:36 Glenn: Looks like Pierre responded... 14:54:51 Pierre: Yes, the note would really help. This was caused by the fact that the terms are 14:54:58 .. identical but mean something different depending on the context. 14:55:00 Glenn: OK 14:55:14 RESOLUTION: Add a note as per the comments in the issue. 14:55:25 Topic: Move processor conformance out of #validation ttml2#689 14:55:32 github: https://github.com/w3c/ttml2/issues/689 14:56:05 Pierre: I think there is still a problem. We have a conformance section, §3, where conformance 14:56:17 .. of various kinds of processors is defined, and suddenly in the validation feature there is 14:56:32 .. a definition of a validating processor and I don't know why this is done but not in §3. 14:56:44 Glenn: There is no such thing as a validation processor, though I did discover two non-normative 14:56:58 .. uses of that in the Introduction, which I can remove. A validating processor is a sub-processing 14:57:11 .. step of a content processor, either a transformation or a presentation processor. There 14:57:26 .. is no such thing as a standalone validation processor. It's an optional bit that gets turned on. 14:57:35 .. So there's no need to add a separate definition. 14:57:50 Pierre: An implementation today can be either a transformation or a presentation processor. 14:58:03 .. Why not define a validation processor and an implementation could be all three at once? 14:58:07 Glenn: There's no need to. 14:58:23 .. The only reason for doing so is for the purpose of making claims. Nobody is going to make 14:58:38 .. a validating content processor that is only a validation processor in my opinion, and if 14:58:51 .. they wanted to do so it would be a validating transformation processor with a yes/no outcome. 14:59:01 .. There is no need to add a new class. 14:59:38 Pierre: Then lets remove the words "is a validating content processor". 14:59:48 Glenn: But that's the point of that section... 15:00:48 Nigel: I'm struggling to see the problem here. 15:01:38 Pierre: The `#validation` feature designators is unique amongst all the feature designators 15:01:48 .. because it imposes more than the processing of vocabulary but also conformance to 15:01:59 .. a particular validating content processor definition. My suggestion is that if there is really 15:02:14 .. such a thing as a validating content processor then it should be defined in the section 15:03:22 .. on conformance. Either way "is a validating content processor" should be removed, and 15:03:33 .. if there is a validating content processor then it should be added to §3. 15:04:05 Nigel: Okay point 1, why should we not remove bullet 1 from `#validation`, i.e. remove 15:04:22 .. the words "is a validating content processor". 15:04:34 Glenn: This is not the first feature designator that does not define a syntactic construct, 15:04:43 .. e.g. lineBreak-uax14. 15:05:04 .. The current specification of ttp:validation does not mandate support for a validating content processor, 15:05:18 .. it defines semantics that apply to a validating content processor but does not require 15:05:35 .. it to be one. I could just move support requirement to ttp:validation. 15:06:22 Nigel: Isn't support for `#validation` something that implies that the supporting processor 15:06:35 .. is a validating processor? 15:06:43 Glenn: It would mean that logically there is no effect. 15:07:24 .. The `#speech` designator uses the same language. We don't define a conformance 15:08:03 .. section for a speech synthesis processor. 15:08:21 Nigel: They aren't identical, you could use the same approach for speech to validation. 15:08:29 Glenn: There are two things I could do: 15:08:43 .. I could use more of the approach taken within `#speech`. 15:09:25 q+ 15:09:37 .. Or I could use the phrasing from speech to make it explicit that validation is an optional 15:09:42 .. component of any content processor. 15:10:20 ack pal 15:10:37 Pierre: I still don't understand - the current definition says "if it is a validating content processor" 15:10:46 .. I follow the link to the definition and it doesn't tell me anything. 15:11:08 Glenn: That's a good point, which I was thinking about. The real intent is to implement the 15:11:20 .. semantics of §5.3.1. 15:11:35 Pierre: Why not just say that, instead of "is a validating content processor" just say 15:11:48 .. "implements the semantics of §5.3 Validation"? 15:12:01 Glenn: I could do that, I would prefer to do it in the definition of the validating content processor, 15:12:12 .. because then I could do the same for the speech processor to make them congruent. 15:12:26 Pierre: Then the definitions section starts to look like a conformance section, which is my 15:12:29 .. point at the end of the day. 15:12:43 Glenn: You could say that for everything. We are not going to create a conformance section 15:12:51 .. for each of the defined features? 15:13:54 Nigel: Would you accept a change to the definition Pierre? 15:14:08 Pierre: No the feature should just refer to §5.3 directly. 15:14:42 Glenn: [scribe paraphrases: this is about consistency across the spec] 15:15:39 Nigel: The question is Pierre would you be able to accept the reference intermediated through the definitions section? 15:15:45 Pierre: I would need to study it further. 15:16:04 SUMMARY: @skynavga to prepare a pull request as per the above discussion for further review. 15:16:09 github-bot, end topic 15:17:25 Topic: The #extent-measure designation includes the value auto. ttml2#690 15:17:53 s/Topic: The #extent-measure designation includes the value auto. ttml2#690/ 15:18:12 Topic: Use of PNG image format. ttml2#694 15:18:19 github: https://github.com/w3c/ttml2/issues/694 15:18:41 Glenn: For this and #605 Mike has suggested that we define features, which I'm happy to 15:19:38 .. do but I don't know exactly to reference. 15:19:55 .. I can't do anything without a proposal for a format definition document. 15:20:06 .. Like the ISO definition and reference number etc. I need guidance. 15:20:23 Pierre: You can use the definitions from IMSC1. 15:20:30 Glenn: Did you define a feature there? 15:20:50 Pierre: No, but if it had one then we could add it to IMSC. 15:20:58 Glenn: Is there a PNG HDR ref? 15:21:16 Pierre: There's the document we published, which references the PNG format. 15:21:33 Glenn: I suggest incorporating the reference from the note and informatively referencing 15:21:38 .. the note as additional information. 15:21:50 Pierre: Both the note and IMSC refer to the same W3C PNG document. 15:21:56 Glenn: Okay. That's fine. 15:22:01 .. I have enough info to proceed. 15:22:25 SUMMARY: @skynavga to proceed with the new information provided above. 15:22:36 github-bot, end topic 15:23:03 Topic: Use of HDR images. ttml2#695 15:23:12 github: https://github.com/w3c/ttml2/issues/695 15:23:26 SUMMARY: As per https://github.com/w3c/ttml2/issues/694#issuecomment-389905466 15:23:29 github-bot, end topic 15:24:01 Topic: Negative feature designators aren't future proof. ttml2#697 15:26:18 Nigel: (summarises issue as relating to feature comparison arithmetic and future proofing_ 15:26:37 .. possible solutions are to whitelist the syntax and semantics which I understand is a lot 15:26:55 .. of work, or to reference the original definition from TTML1. I wanted input from the group 15:27:09 .. because that pushes the effort onto the reader of the spec to understand the diff between 15:27:13 .. TTML1 and TTML2. 15:27:53 Glenn: There's a separate related issue to reference TTML1 feature designator definitions from 15:28:13 .. feature designators that are carried forward into TTML2. 15:28:37 .. That bumps the definition back to TTML1 that is already in the wild. 15:28:52 .. The second part is the request to specify attributes and elements and even listing values. 15:29:04 .. That would be a complicated process and prone to error and ambiguity because you either 15:29:05 q+ 15:29:22 .. have to repeat the definition or you have to summarise or paraphrase it which is a 15:29:37 .. reduction that might result in ambiguity. It also breaks the "don't say it twice" rule. While 15:29:58 .. we do that in some places already, e.g. adding rw and rh units to length, which are very 15:30:18 .. simple, but for larger features like ruby-reserve or the tts:ruby attribute it would be 15:30:37 .. impractical to paraphrase the meaning of that so we followed the formula from TTML1. 15:30:46 .. We don't call out all the sub-features of the attribute. 15:31:03 .. While I admit we already have some features with a whitelist those are the exception 15:31:14 .. rather than the rule and I don't want to set a rule. 15:31:17 ack pal 15:31:30 Pierre: The large number of features that would be affected can not be a reason not to do it 15:31:52 .. because the obvious answer is to get rid of features that nobody cares about. Or we can 15:31:55 .. do it. 15:32:00 Glenn: We'll be here until next year. 15:32:12 Pierre: Or we can let Nigel do it. The large number of features cannot be an excuse. 15:32:36 Glenn: The review work would be just as much! 15:34:05 .. You've approached this from a generic speculative perspective. I would rather tackle 15:34:20 .. this from a bottom-up perspective where we fix individual problems where we find them, 15:34:36 .. and if we can synthesise a rule then we can apply that. 15:35:12 q+ 15:36:05 Nigel: I think the counter to this is to mark feature combination as at risk. 15:36:15 Glenn: That's reasonable. Do we have a feature for that? I am thinking we don't. 15:36:27 ack atai 15:36:29 ack pal 15:36:44 Pierre: Does your comment Nigel apply to those features worded as "Notwithstanding the 15:38:20 .. above support for xyz is not implied"? 15:39:01 Nigel: I haven't thought about that - the examples I was thinking of were listed in the issue, 15:39:10 .. such as `#textEmphasis-no-color`. 15:39:27 Glenn: Nigel you contend that "all defined values" is open-ended but I would contend that 15:39:42 .. it is not, in that the defined values are those in this version of the specification. 15:43:07 Nigel: I suppose that's logical and we're referring to TTML1 for TTML1 defined features. 15:43:27 .. Logically we could future-proof ourselves against later versions by specifying TTML2 15:43:33 .. for newly introduced features also. 15:44:10 Glenn: We need concrete examples to solve here. 15:44:43 Nigel: Going back to the main question I wanted to ask the group: is it okay to refer the 15:45:03 .. reader back to TTML1 for features defined there? Any objections to doing that? 15:45:17 group: [silence] 15:45:25 Nigel: I'll take that as assent to adopt that approach then. 15:45:53 RESOLUTION: Mark TTML1 features as relating to the TTML1 definition 15:46:34 SUMMARY: This resolution is logged as #763 15:46:41 github-bot, end topic 15:46:59 Topic: Rewrite version 1 features as references to [TTML1]. ttml2#763 15:47:05 github: https://github.com/w3c/ttml2/issues/763 15:47:45 RESOLUTION: Do this, as agreed in today's meeting. 15:47:48 github-bot, end topic 15:49:32 Topic: Disallow ` left` and ` right` syntax. ttml2#711 15:49:42 github: https://github.com/w3c/ttml2/issues/711 15:50:05 Glenn: The open question is whether to adopt the CSS restriction on position. My contention 15:50:13 .. is that there is no ambiguity. 15:51:06 .. Do we want to remove the ability to have vertical first, so you could not say "top left". 15:51:22 .. When both are keywords, English conventions argues for allowing "top left" and "bottom right" 15:51:38 .. but you want to make `top ` not permitted? 15:51:39 Pierre: Yes 15:51:55 Glenn: Because in that case the second position length is horizontal not vertical and you 15:52:06 .. want to resolve length as horizontal first and vertical second. 15:52:09 Pierre: Yes 15:52:25 Glenn: I can implement the CSS restriction if that's what the group wants. I think I 15:52:40 .. implemented this and didn't have any difficulty. I can go along with that for CSS consistency. 15:53:02 Nigel: I would second that, for CSS consistency. Any objection to applying the CSS rule here? 15:53:09 group: [no objection] 15:53:34 RESOLUTION: Adopt the CSS constraints on ordering 15:53:54 Topic: Definition of implicit inline region ttml2#727 15:54:00 github: https://github.com/w3c/ttml2/issues/727 15:55:48 Nigel: The discussion point here relates to the pull request #731. We don't have implied 15:56:01 .. inline regions at all anymore, so the feature designator is wrong. 15:56:17 Glenn: I guess I could change region-inline-explicit to region-inline. 15:56:40 .. I would prefer `#region-animation-implicit` for the other one. 15:56:53 s/region-inline-explicit/#region-inline-explicit 15:57:00 s/region-inline/#region-inline 15:57:03 Nigel: OK 15:57:30 Glenn: I'll address the wording too. 15:57:36 Nigel: Okay, thank you. 15:57:54 SUMMARY: @skynavga to update the pull request as per the discussion above. 15:57:57 github-bot, end topic 15:58:50 atai2 has left #tt 15:59:36 Topic: Featurize offset times w/o metric. ttml2#752 15:59:46 github: https://github.com/w3c/ttml2/issues/752 16:00:12 Glenn: I'll prepare a pull request to bring this back to TTML1 syntax by removing the 16:00:27 .. optionality of metric. Then we can hold off on review until the pull request stage. 16:00:29 Nigel: Sounds good. 16:00:49 SUMMARY: @skynavga to prepare a pull request to remove the optionality of metric on time expressions 16:01:20 github-bot, end topic 16:02:40 Topic: Meeting close 16:02:53 Nigel: Thanks everyone. Reminder: no meeting next week. [adjourns meeting] 16:02:59 rrsagent, make minutes 16:02:59 I have made the request to generate https://www.w3.org/2018/05/17-tt-minutes.html nigel 16:42:49 scribeOptions: -final -noEmbedDiagnostics 16:42:50 rrsagent, make minutes 16:42:50 I have made the request to generate https://www.w3.org/2018/05/17-tt-minutes.html nigel 16:45:53 nigel has changed the topic to: TTWG meetings Thursdays 1000 Boston time. Minutes for most recent call: https://www.w3.org/2018/05/17-tt-minutes.html Next meeting 2018-05-31. 18:02:40 Zakim has left #tt