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