15:59:43 RRSAgent has joined #tt 15:59:47 logging to https://www.w3.org/2024/02/29-tt-irc 16:00:18 RRSAgent, make logs Public 16:00:19 Meeting: Timed Text Working Group Teleconference 16:00:19 scribe: nigel 16:00:19 Present: Nigel 16:00:19 Chair: Nigel 16:00:21 Regrets: Gary 16:00:34 Agenda: https://github.com/w3c/ttwg/issues/277 16:00:45 Previous meeting: https://www.w3.org/2024/02/15-tt-minutes.html 16:00:52 rrsagent, make minutes 16:00:53 I have made the request to generate https://www.w3.org/2024/02/29-tt-minutes.html nigel 16:02:42 Present+ Andreas 16:02:53 Topic: This meeting 16:04:58 Present+ Cyril 16:06:24 Present+ Atsushi 16:06:43 Nigel: Today we have IMSC-HRM (PR publication?) 16:07:04 .. DAPT issues and pull requests 16:07:10 present+ Matt 16:07:26 .. Upcoming DST changes 16:07:39 .. Anything else for the agenda, or to make sure we cover in the topics mentioned? 16:07:50 no other business 16:08:04 Topic: IMSC-HRM 16:08:18 Present+ Pierre 16:08:33 Atsushi: PR was published today. End of review is March 28/29 (depending on time zone) 16:08:49 .. We need to get some AC rep reviews, so please ask your reps to submit a review. 16:09:20 -> https://www.w3.org/TR/2024/PR-imsc-hrm-20240229/ IMSC-HRM Proposed Recommendation 16:09:26 Nigel: That's great news, thank you. 16:09:33 atai has joined #tt 16:09:41 .. Apologies from me that we had a bit of a rocky time getting to this point! 16:10:08 Atsushi: Also apologies from me that I haven't built a proper set of materials for final review before I asked 16:10:20 s/asked// 16:10:38 .. submitted the transition request. 16:11:14 Nigel: No need, we thought we had done that! 16:11:14 .. Anyway, thank you to everyone for getting us to this point, 16:11:23 .. and reinforce the message - get AC reviews on the WBS poll they have received, please. 16:11:39 .. I think this is now out of our hands! Is there anything else to say about it? 16:12:18 .. Just one thing from me. In the WBS poll it mentions that there is one open issue. 16:12:50 .. In that issue I made a comment proposing to defer taking any action, so I don't know if we should 16:13:01 .. say anything about that in the WBS? 16:13:17 Atsushi: There is no reason to restate that it is not intended to be included in this version, because 16:13:28 .. that's implied by PR publication, that there are no more changes planned. 16:13:31 Nigel: OK. 16:13:41 .. Anybody clicking on the link to the issue will see that anyway. 16:14:03 Pierre: Thanks everybody, I will merge the pull request to reflect the PR publication. 16:14:06 Nigel: Thanks. 16:14:41 Topic: DAPT issues and pull requests for discussion 16:14:59 -> https://github.com/w3c/dapt/labels/agenda issues for agenda 16:16:03 Cyril: I wonder if we can aim for a CR date, since we are getting very close? 16:16:10 .. We had a list of issues marked as Must Have for CR. 16:16:18 .. We should review and see if they are still Must Have. 16:16:32 Nigel: Good point. I think the proposal with all of those issues marked Must Have for CR 16:16:52 .. is to make them "at risk" features, which is a pull request I think I should raise. 16:17:22 .. I think we pencilled in a date for getting to CR before, I can't recall when. 16:17:34 Cyril: Is it reasonable to ask for a CfC at the next meeting, 2 weeks from now? 16:19:37 Nigel: Looking at the list of open issues, I don't think we have a proposal for all the issues, and I think we 16:19:40 .. need one. 16:20:00 Cyril: Perhaps we can have an Editors meeting to generate proposals on those and see if we can do a CfC in 16:20:02 .. next meeting? 16:20:07 Nigel: Ok, happy to try for that. 16:20:20 Cyril: Andreas, any issues to be addressed before CR. Others? 16:20:25 Andreas: No I don't think so. 16:20:41 Pierre: I don't have any strong feelings one way or the other but my experience is that making changes 16:20:57 .. after CR is a lot harder, or you have to be prepared to do multiple CRs, which is probably easier now. 16:21:18 Cyril: Thank you Pierre. At the same time if we think we're going to make a better spec every time we're just 16:21:20 .. delaying. 16:21:33 Pierre: You're preaching to the choir! It's good to have a deadline. 16:21:52 Atsushi: Making changes after the first CRS: If we add substantial changes we need to have a review 16:22:02 .. of the changes before the next CRS or before transitioning to PR. 16:22:13 .. Also we need to identify any specific at-risk sections. 16:22:26 .. I'm not sure about the potential changes or developments. I don't think we need to mark them 16:22:45 .. as at risk though. In any case, a delta review is not a full review, but is usually done over specific 16:22:54 q+ 16:22:58 .. changed items. I believe it is not so heavy as first CR publication. 16:23:01 ack atai 16:23:09 Andreas: I definitely don't want to hold back the publication. 16:23:28 .. I remember we had some issues where we said we may have different opinions but we want implementation experience. 16:23:35 .. Do we have to look at these again? 16:23:48 .. Also, when I do my reviews I take time to look over the complete spec to see all changes together. 16:24:03 .. In the last weeks and months the spec has changed considerably, I'm sure for the better. 16:24:15 .. We need to allow time to make it possible to have a complete review. 16:24:22 .. That could be the CfC, I don't know. Just a thought. 16:24:58 Nigel: There are probably a number of pull requests that need to be opened and merged quite soon to deal with some issues. 16:25:05 .. I think they can be rolled into a CfC as well. 16:25:23 Cyril: I think an editor's call can result in pull requests and the CfC can be pending review of them. 16:25:33 .. I don't mind 2 or 4 weeks but I would like to get us started. 16:25:37 Nigel: Agreed! 16:25:51 Cyril: I don't think we're missing any features. In the past month we've been clarifying things but 16:25:59 .. not adding any features, just making sure things work together. 16:26:01 Nigel: Yes 16:26:49 .. That feels achievable to me. Editor's call tomorrow or next week, then PRs out, then CfC for CR publication request. 16:27:58 Subtopic: Clarifying what is normatively permitted in a DAPT document 16:28:03 Nigel: Two related comments: 16:28:12 -> https://github.com/w3c/dapt/issues/192#issuecomment-1967324217 16:28:36 -> https://github.com/w3c/dapt/pull/158#discussion_r1491466316 16:29:12 Nigel: The topic here is thus: 16:29:42 .. Right now DAPT defines a data model and a mapping from that model into TTML, 16:29:57 .. plus a set of formal TTML features and extensions that are optional or required for processors. 16:31:22 .. In issue #192 Clarify language application and inheritance model we had a conversation about 16:31:39 .. whether we should say that language is inherited from an element that otherwise doesn't look like it can 16:31:56 .. have language specified on it, i.e. Script Event Description inheriting language from Script Event 16:32:24 MattS has joined #tt 16:32:44 .. The other point is in pull request #158 clarify what spans are possible in a text and how they are handled 16:33:30 .. Cyril asked about bidirectional mapping e.g. what if the TTML elements representing a Character, contain more than the few elements specified in the spec 16:34:48 .. I made a proposal that the TTML2 features and extensions dispositions are the normative specification. 16:34:58 .. The other thing I think we should take care about is the Data Model section is normative 16:35:14 .. and we may need to be careful about whether the diagram is considered normative or not. 16:35:36 q+ 16:35:45 Cyril: I understand the commonality between these two things. I think they can still be considered separately. 16:35:58 ack atai 16:36:08 Andreas: I think you summarised the main issue from my perspective. 16:36:18 .. There is a lot more possible in the syntax representation than the data model. 16:36:36 .. That may be confusing for the user. xml:lang is just an example. You can use it on body and div 16:36:40 .. but it's not mentioned in the spec. 16:36:49 .. Some people might use it but implementers might ignore it. 16:37:03 .. The relationship between data model and syntax representation may need to be made clear. 16:37:14 .. Either say that more might be in the document than in the data model, 16:37:23 .. or recommend that people write TTML documents that conform to the data model. 16:37:32 .. At least some clarifying text would be useful. 16:37:57 Cyril: On the xml:lang question I think an easy solution would be to allow language on script events. 16:38:02 .. It wouldn't hurt and would make it easy. 16:38:21 .. On the span question, my point in the pull request is that the text goes beyond what the rest of the spec does. 16:38:39 .. Instead of saying the data model is represented by, the current text says how you go from the representation 16:38:50 .. back to the data model. I think this is the only place we do that, so I think that's the question. 16:39:05 .. I understand it's a TTML2 profile, but at the same time the idea is it should be simple and people should 16:39:22 .. be able to implement the data model not the whole of TTML2 so I wouldn't be against more restrictions 16:39:35 .. to avoid allowing things that cannot be mapped back to the data model. 16:39:49 Nigel: Do you think the data model should be normative? 16:40:07 q+ 16:40:15 Cyril: I thought it was? 16:40:29 Nigel: We generally avoid normative language in the data model, and put it mostly in the representation. 16:40:44 Cyril: I recognise we are doing two things at the same time, and its a recipe for mismatch. 16:41:00 .. We should strive to make them match but I agree with Andreas's point we should recommend adhering to the 16:41:12 .. model but strictly speaking be prepared a document that goes beyond the data model because the TTML2 16:41:15 .. syntax permits it. 16:41:26 ack atai 16:41:38 Andreas: I agree with Cyril, at least with the option, to just allow in the syntax what is in the data model. 16:41:54 .. I'm not sure how much work it would be to make this, because maybe several parts of the spec are affected. 16:42:00 .. It makes the implementation easier. 16:42:13 .. This is something people complain about with TTML, with some of the existing profiles. 16:42:18 .. That would be the strongest solution maybe. 16:42:39 .. Another would be a weaker recommendation to use it like the data model says. 16:42:45 Nigel: Couple of points. 16:43:06 .. First I think we should explicitly state that the diagram is informative, in case there's an unintended 16:43:11 .. clash between the diagram and the text. 16:43:28 .. Second, I am wary of making implementations more complex rather than less complex by introducing more 16:43:54 .. conditions on what is permitted on specific elements. For example, it's easy to implement generic 16:44:10 .. xml:lang inheritance when it can be set on every element in the tree, but if you restrict to only certain 16:44:22 .. element types then that adds implementation complexity. 16:44:33 .. I think we need to tread the line carefully. 16:44:52 .. There definitely are cases where we would want specific restrictions. 16:45:51 .. Options I've heard so far (maybe not mutually exclusive): 16:46:01 .. 1. Add additional restrictions via extension features 16:46:08 .. 2. Make data model diagram informative 16:46:22 .. 3. Recommend only making TTML2 documents that match the data model 16:46:34 .. any others? 16:46:49 Cyril: I think we should do some sort of analysis of the possible differences. 16:47:04 .. An alternative would be to say not that we put restrictions in the syntax, but indicate processing 16:47:20 .. behaviours when encountering syntax that does not adhere to the data model, but that is TTML acceptable, 16:47:40 .. maybe recommend that processors may or should ignore it, to allow a simplified implementation. 16:48:00 .. One example: today we say a script is made of a list of script events where each is a div with a specific syntax. 16:48:14 q+ 16:48:22 .. What if you encounter an extra div that is used for some other purpose and does not match the requirements of a Script Event? 16:48:33 .. I think processor-recommended behaviour might be a good option. 16:48:39 ack ata 16:48:49 Andreas: That's what I think Nigel meant by making things more complex. 16:49:09 .. For example different processor behaviour for DAPT processors than generic TTML processors may be a problem. 16:49:25 .. With xml:lang, if you ignore it on body or div then it may not work, and that would add complexity. 16:49:39 Cyril: I understand that, I think we all agree we don't want that behaviour. 16:49:46 .. Maybe there are cases where this could be applicable. 16:50:45 Nigel: My other suggestion is to clarify that the TTML2 feature support required by the specification defines 16:50:59 .. the processor behaviour, even if there's a difference from the data model. 16:51:51 .. In the example that Cyril gave before of a non-Script Event div, if an implementation doesn't know what to do 16:52:08 .. with it I think I'm not that unhappy with it being an implementation behaviour, for example in an authoring tool. 16:52:17 Andreas: I think a clear guideline is needed for implementers. 16:52:32 .. I agree with Cyril's proposal to do some analysis. 16:52:56 .. If we say that TTML2 governs if there are differences it could lead to a sense of lack of clarity or uncertainty, 16:53:06 .. and make people look more deeply into TTML2 to get these cases. 16:53:39 Cyril: I wonder if we should add to the "is represented by" some statement about processing behaviour 16:53:58 .. if other elements or attributes are encountered then the extensibility clause applies, or whatever. 16:54:11 .. I wonder if a way to be exhaustive would be to do that systematically for every section, to make sure we don't 16:54:14 .. miss anything. 16:54:49 Nigel: I think it's best to do this before CR, but I think doing this puts the 2 week suggestion under threat! 16:54:59 Cyril: I get that - this one is a true CR must have I would say. 16:55:24 Pierre: When was the last draft published? 16:55:28 Nigel: 15th February 16:55:34 Cyril: We publish on every pull request merge 16:56:02 .. I propose to open a new issue to try and address this, identifying potential gaps between syntax capabilities 16:56:05 .. and the model. 16:56:14 .. That's an action for me. 16:56:22 .. Are we okay to merge the pull request? 16:57:01 Nigel: I've approved this, I think we're fine unless anyone objects. 16:57:15 Cyril: I can open the issue and merge the pull request with a note that further discussion will continue on the issue. 16:57:18 Nigel: Sounds good to me. 16:57:39 Cyril: On the xml:lang, would there be any objection to allowing Language on the Script Event? 16:57:42 Nigel: I think it's premature 16:57:55 Pierre: I've lived through that painfully in IMSC. Is it limited today? 16:58:02 Cyril: in XML syntax no, but in data model yes. 16:58:13 Pierre: My experience with IMSC: I'd treat the two completely separately. 16:58:28 .. The xml:lang in XML has a specific set of rules for inheritance. I would not try to restrict that at all. 16:58:43 .. Just follow the inheritance rules in the XML, where every element in the hierarchy has a computed value 16:59:01 .. of xml:lang, and then when you map that back to the model you use the computed value. 16:59:21 .. Trying to limit it in XML is super hard. Just let it be and use the computed value to infer the values in the model. 16:59:30 Nigel: I think you've pointed the way forward there. 17:00:07 Pierre: Let's say the data model says there's no Language on an element , you just ignore it on things where it's not in the data model. 17:00:26 Nigel: I think that's it - stuff can be in the syntax but only has significance on objects in the data model. 17:00:39 Pierre: I think that's the idea in TTML - applies to xml:space and everything else really. 17:01:58 Nigel: Thanks we're out of time on this but that's a good point to end this discussion. 17:02:03 Topic: DST changes 17:02:18 Pierre: my input is 7am Pacific and 10am Pacific are impossible for me, but 8am and 9am are fine. 17:02:30 Nigel: We're out of time today so will have to move this offline. 17:02:49 Cyril: Same for me as Pierre - 7am Pacific is a stretch but 8am or 9am works. 17:03:08 Nigel: I'll have to do the mapping to understand what that means in practice 17:03:29 .. I think in previous years we have tracked America on this change because it's not so onerous in Europe. 17:03:51 Atsushi: I wondered which direction things would go here. 17:04:00 Nigel: You've got i18n too, which must have the same problem. 17:04:16 Atsushi: Usually i18n sticks to UK. 17:04:26 Nigel: You could end up with a clash I think. 17:08:48 Topic: Meeting close 17:11:06 Nigel: Thanks everyone, apologies that we've run over today. [adjourns meeting] 17:11:10 rrsagent, make minutes 17:11:11 I have made the request to generate https://www.w3.org/2024/02/29-tt-minutes.html nigel 17:15:07 nigel has joined #tt 17:36:37 nigel has joined #tt 17:37:27 scribeOptions: -final -noDiagnostics 17:37:29 zakim, end meeting 17:37:29 As of this point the attendees have been Nigel, Andreas, Cyril, Atsushi, Matt, Pierre 17:37:31 RRSAgent, please draft minutes v2 17:37:32 I have made the request to generate https://www.w3.org/2024/02/29-tt-minutes.html Zakim 17:38:10 I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye 17:38:10 Zakim has left #tt 17:39:45 scribeOptions: -final -noEmbedDiagnostics 17:39:51 rrsagent, make minutes 17:39:52 I have made the request to generate https://www.w3.org/2024/02/29-tt-minutes.html nigel 17:40:55 rrsagent, excuse us 17:40:55 I see no action items