IRC log of tt on 2024-09-12
Timestamps are in UTC.
- 14:59:28 [RRSAgent]
- RRSAgent has joined #tt
- 14:59:32 [RRSAgent]
- logging to https://www.w3.org/2024/09/12-tt-irc
- 14:59:32 [Zakim]
- RRSAgent, make logs Public
- 14:59:33 [Zakim]
- Meeting: Timed Text Working Group Teleconference
- 14:59:36 [nigel]
- scribe: nigel
- 14:59:39 [nigel]
- Chair: Nigel, Gary
- 14:59:43 [nigel]
- Present: Nigel
- 14:59:52 [nigel]
- Agenda: https://github.com/w3c/ttwg/issues/290
- 15:00:00 [nigel]
- Previous meeting: https://www.w3.org/2024/08/29-tt-minutes.html
- 15:00:18 [nigel]
- rrsagent, make minutes
- 15:00:20 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/12-tt-minutes.html nigel
- 15:01:34 [nigel]
- Present+ Andreas, Cyril, Gary
- 15:01:45 [nigel]
- Topic: This Meeting
- 15:02:01 [atai]
- atai has joined #tt
- 15:03:23 [nigel]
- Nigel: Today we have DAPT, IMSC and TPAC planning. Any other business?
- 15:03:46 [nigel]
- no other business
- 15:04:00 [nigel]
- Topic: DAPT
- 15:04:09 [nigel]
- Subtopic: CR Must-have issues
- 15:04:40 [nigel]
- Present+ Atsushi
- 15:04:56 [nigel]
- -> https://github.com/w3c/dapt/issues?q=is%3Aissue+is%3Aopen+label%3A%22CR+must-have%22 CR must-have issues
- 15:05:21 [nigel]
- Nigel: Last week we said we'd try to get PRs open for today so that they will have had a long enough
- 15:05:36 [nigel]
- .. approval period to merge in time to agree to publish CR at TPAC
- 15:06:08 [nigel]
- .. I've opened 3 pull requests, one can be merged tomorrow if not today
- 15:07:44 [nigel]
- .. w3c/dapt#237 Add nested div feature and mark as permitted, at risk
- 15:07:56 [nigel]
- .. That was a technical one, can be merged tomorrow I think.
- 15:08:08 [nigel]
- .. w3c/dapt#233 I'd like to come back to.
- 15:08:21 [nigel]
- .. w3c/dapt#232 I opened a PR for last night
- 15:08:29 [nigel]
- Cyril: I'm not sure about the approach, let's talk about it.
- 15:08:34 [nigel]
- Nigel: OK
- 15:09:10 [nigel]
- .. w3c/dapt#227 to merge represents and script event type, which I just opened earlier today,
- 15:09:17 [nigel]
- .. which we can have a quick look at.
- 15:09:52 [nigel]
- .. Then we had 75 and 44 which Cyril was going to have a look at.
- 15:10:05 [nigel]
- Cyril: I think we can close them, shall we discuss them, maybe start with #75?
- 15:10:09 [nigel]
- Nigel: Let's do that
- 15:10:41 [nigel]
- Subtopic: Consider defining restrictions per Script Type w3c/dapt#75
- 15:10:49 [nigel]
- github: https://github.com/w3c/dapt/issues/75
- 15:11:01 [nigel]
- Cyril: A lot of things have changed since this was opened.
- 15:11:20 [nigel]
- .. The gist of this issue is, if I place myself as a Netflix receiver of scripts,
- 15:11:34 [nigel]
- .. I want to be able to validate that if I receive a dubbing script it's not an audio description script,
- 15:11:37 [nigel]
- .. and vice versa.
- 15:12:00 [nigel]
- .. I can see that if somebody delivers a dubbing script to Netflix we will check that the <audio>
- 15:12:09 [nigel]
- .. element is not present in it, and reject a delivery if it does, for example.
- 15:12:21 [nigel]
- .. We do that for subtitles, have additional restrictions not in IMSC but Netflix-specific.
- 15:12:42 [nigel]
- .. When I opened this issue I wondered how many of these restrictions should be core vs
- 15:13:04 [nigel]
- .. organisation specific. I thought it would make sense to distinguish these transcript types.
- 15:13:21 [nigel]
- .. For example in an original transcript each event should have at most one <p> and the language source
- 15:13:27 [nigel]
- .. should be equal to the xml:lang always.
- 15:13:50 [nigel]
- .. We can go to CR without this. The risk is that the actual profile that is implemented has more
- 15:14:09 [nigel]
- .. restrictions than what it specified in the spec, and some people may impose additional restrictions than
- 15:14:13 [nigel]
- .. the spec.
- 15:15:17 [nigel]
- Nigel: What should we do - take the label off, or close with no action?
- 15:15:50 [nigel]
- .. I think we're missing a proposal for what these per-script type restrictions would be.
- 15:16:02 [nigel]
- Cyril: I realise that, we could still decide to go to CR without them.
- 15:16:06 [nigel]
- Nigel: I think so, yes.
- 15:16:13 [atai]
- q+
- 15:16:34 [nigel]
- Cyril: This could be a good segue into the discussion about represents.
- 15:16:37 [nigel]
- ack at
- 15:16:52 [nigel]
- Andreas: Apologies I lost a bit of progress on the spec.
- 15:17:13 [nigel]
- .. Just to check the use case, it is to work out whether a script is a dubbing script or an audio description script?
- 15:17:19 [nigel]
- .. I think that is a reasonable use case.
- 15:17:31 [nigel]
- q+
- 15:17:38 [nigel]
- Present+ Pierre
- 15:18:17 [nigel]
- ack ni
- 15:18:29 [nigel]
- Nigel: This has hurt my head in the past because I'm not sure how prescriptive we are about
- 15:18:45 [nigel]
- .. the different lifecycle stages for getting to localised versions - is an original language transcript
- 15:19:09 [nigel]
- .. a dubbing script, say? It's a start for one, or for subtitles, or both.
- 15:19:38 [nigel]
- Cyril: I would like to keep this open and propose something based on represents
- 15:20:02 [nigel]
- SUMMARY: @cconcolato to make a proposal
- 15:20:25 [nigel]
- Subtopic: Remove Script Event Type, use Represents instead w3c/dapt#241
- 15:20:35 [nigel]
- github: https://github.com/w3c/dapt/pull/241
- 15:24:30 [nigel]
- Nigel: [shows pull request preview]
- 15:24:50 [nigel]
- .. Question about whether to formalise the relationship when a content descriptor is a subset of another one.
- 15:25:02 [nigel]
- Cyril: 2 comments, one editorial, one technical.
- 15:25:21 [nigel]
- .. 1. Editorial: there's no question on the intent, merging the fields is a good decision.
- 15:25:30 [nigel]
- .. Why did you choose to make it a Shared Property?
- 15:25:57 [nigel]
- .. It behaves very similarly to text language source and other attributes.
- 15:26:16 [nigel]
- .. 2. Technical: I think we need to better explain the inheritance model that goes with it.
- 15:26:20 [nigel]
- q+
- 15:26:37 [nigel]
- .. To me, I see Represents as similar to xml:lang or daptm:langSrc - you specify it somewhere and it
- 15:26:49 [nigel]
- .. applies to the whole tree, and if you specify it somewhere else it is possibly to narrow down the value
- 15:27:00 [nigel]
- .. for that part of the tree, a group of divs or one div.
- 15:27:16 [nigel]
- .. For example for a dubbing script a represents at the top level could say "dialog nonDialogSounds"
- 15:27:28 [nigel]
- .. and for specific events you would say this is a dialog or a nonDialogSound.
- 15:27:48 [nigel]
- .. We shouldn't be able to say something in represents at the top level and then contradict that at a lower level,
- 15:28:06 [nigel]
- .. e.g. by not having any nonDialogSounds in the body but claiming it at the root.
- 15:28:11 [nigel]
- ack nige
- 15:28:25 [nigel]
- Nigel: My thinking here is that there is no inheritance model
- 15:29:12 [nigel]
- .. You could make the inheritance model one where you replace an inherited value with one
- 15:29:21 [nigel]
- .. specified at a lower level, but additive inheritance would not work.
- 15:32:23 [nigel]
- .. Let's say I commission a transcript including dialog and nonDialog sounds, but the media
- 15:33:43 [atai]
- atai has joined #tt
- 15:34:37 [nigel]
- .. has no nonDialogSounds, then it makes sense to have no Script Events that represent nonDialogSounds.
- 15:35:14 [nigel]
- [discussion of inheritance, inclusion and exclusion constraints]
- 15:35:27 [atai]
- q+
- 15:36:05 [nigel]
- Gary: Could the top level one be a default one?
- 15:36:19 [nigel]
- Nigel: Could make represents mandatory on Script Events
- 15:36:33 [nigel]
- Cyril: Can't have a single Script Event be visual and nonVisual at the same time.
- 15:36:37 [nigel]
- ack at
- 15:37:00 [nigel]
- Andreas: Why can't we apply the same inheritance rule as xml:lang, so that the lowest
- 15:37:19 [nigel]
- .. attribute in the tree defines what the event is, so it's not a restriction, it's just overriding what is above.
- 15:37:38 [nigel]
- .. It's a general rule, e.g. for namespaces, xml:lang and others.
- 15:37:50 [nigel]
- .. To make this restriction makes it complicated to validate.
- 15:38:58 [nigel]
- Nigel: It's a list, and it only applies to the element it is on.
- 15:39:12 [nigel]
- Cyril: In that case your idea to make it mandatory on Script Event is probably better.
- 15:39:17 [nigel]
- .. It would lead to some verbosity.
- 15:39:45 [nigel]
- Gary: An alternative is to have represents be a single item and have a documentRepresents with a list
- 15:39:49 [nigel]
- Cyril: Could do that
- 15:40:02 [nigel]
- Gary: Then you could do normal inheritance
- 15:40:22 [nigel]
- Cyril: It's like langSrc, where the document can have multiple source languages
- 15:40:44 [nigel]
- .. I realise that langSrc is just one value but I thought we discussed having multiple values
- 15:41:48 [nigel]
- Nigel: Need to close this due to time. Please add comments to the issue clarifying the requirements.
- 15:41:51 [nigel]
- Cyril: OK
- 15:42:11 [nigel]
- SUMMARY: Reviewers to consider the PR and if necessary comment regarding the requirements, in the issue.
- 15:43:01 [nigel]
- Subtopic: Add legacy metadata structure and media zero timecode metadata w3c/dapt#240
- 15:43:08 [nigel]
- github: https://github.com/w3c/dapt/pull/240
- 15:43:39 [nigel]
- Cyril: I added my comment already. Why add the legacy structure?
- 15:43:46 [nigel]
- .. Why make it an element not an attribute, e.g. on the tt element?
- 15:44:37 [nigel]
- Nigel: I wanted to provide a home for legacy conversion data, and to make it really clear that
- 15:44:48 [nigel]
- .. it isn't something that should carry any presentation semantics.
- 15:44:56 [nigel]
- .. We could do it the way you suggest, of course.
- 15:45:10 [nigel]
- .. I fear that people won't read the spec and putting the data here gives a really strong hint.
- 15:45:55 [nigel]
- Cyril: I think I raised the point in the past - it's not specific to DAPT, it could be a TTML thing.
- 15:46:13 [nigel]
- .. I understand that we need it in DAPT, but maybe we could define it in the TTML namespace, and transfer
- 15:46:17 [nigel]
- .. it into TTML2 later.
- 15:47:47 [atai]
- q+
- 15:47:49 [nigel]
- Nigel: I'm happy to consider other use cases, I actually don't know of any right now.
- 15:47:51 [nigel]
- ack at
- 15:48:07 [nigel]
- Andreas: I was present when we started the discussion but haven't followed the current solution of the issue.
- 15:48:25 [nigel]
- .. When we started I also had the feeling that it could have wider applicability than DAPT, and have other use cases,
- 15:48:35 [nigel]
- .. so would be better in another namespace, or aligned with the parent specification.
- 15:48:49 [nigel]
- .. Sorry for not fully reviewing what you have proposed here.
- 15:49:03 [nigel]
- .. What we have in EBU-TT, couldn't the same thing be expressed with what you propose here for DAPT?
- 15:49:21 [nigel]
- Nigel: I don't think so, happy to be shown otherwise.
- 15:51:17 [nigel]
- .. Need to close for time, please continue to review and discuss.
- 15:51:32 [nigel]
- .. Wonder how strong your feeling is about the data structure as proposed, Cyril?
- 15:51:53 [nigel]
- Cyril: I don't understand the point of the legacy metadata, why it's different from other conversion data.
- 15:52:08 [nigel]
- .. Also would like to see an informative reference to ESEF to explain it.
- 15:52:16 [nigel]
- SUMMARY: Review to continue
- 15:52:38 [nigel]
- Topic: IMSC superscript/subscript support w3c/imsc#583
- 15:52:49 [nigel]
- github: https://github.com/w3c/imsc/issues/583
- 15:53:06 [nigel]
- Nigel: This was discussed in the EBU Media Access Technology group call last Tuesday,
- 15:53:24 [nigel]
- .. and the main summary is that for French especially, if the feature were available it would be used,
- 15:53:38 [nigel]
- .. but French people are used to non-superscript ordinals at the moment.
- 15:53:59 [nigel]
- .. There are other similar use cases for numbers in chemical symbols or in "square metres" etc,
- 15:54:03 [nigel]
- .. in Norwegian and German.
- 15:54:36 [nigel]
- SUMMARY: EBU positive about requirement, unclear if anyone "cannot live without" the feature.
- 15:54:44 [nigel]
- Topic: TPAC 2024
- 15:55:18 [nigel]
- Nigel: We've had agenda requests - see https://github.com/w3c/ttwg/issues/291
- 15:56:48 [nigel]
- Gary: I will be around remotely, at least on the Friday.
- 15:56:54 [nigel]
- Nigel: Time constraints for the WebVTT topics?
- 15:57:13 [nigel]
- Gary: I don't think I have any, I'm good to go at any time during the meeting
- 15:57:47 [nigel]
- -> https://www.w3.org/wiki/TimedText/tpac2024#Agenda_and_Schedule Wiki page
- 15:58:37 [nigel]
- Nigel: If anyone has any constraints on timing, please let us know
- 16:00:08 [nigel]
- .. MediaWG meets in the morning, we may be better using the afternoon for the WebVTT topics
- 16:00:23 [nigel]
- Gary: I'll ping James and Marcos to see if they have any time constraints.
- 16:02:11 [nigel]
- Nigel: Thank you
- 16:02:16 [nigel]
- Topic: Meeting close
- 16:02:36 [nigel]
- Nigel: Thanks everyone. Our next meeting will be, as on the TTWG Calendar, Monday 23rd September,
- 16:02:41 [nigel]
- .. joint with the MEIG.
- 16:02:45 [nigel]
- .. [adjourns meeting]
- 16:02:48 [nigel]
- rrsagent, make minutes
- 16:02:49 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/12-tt-minutes.html nigel
- 16:08:43 [nigel]
- scribeOptions: -final -noEmbedDiagnostics
- 16:08:48 [nigel]
- zakim, end meeting
- 16:08:48 [Zakim]
- As of this point the attendees have been Nigel, Andreas, Cyril, Gary, Atsushi, Pierre
- 16:08:50 [Zakim]
- RRSAgent, please draft minutes v2
- 16:08:51 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/09/12-tt-minutes.html Zakim
- 16:08:58 [Zakim]
- I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye
- 16:08:58 [Zakim]
- Zakim has left #tt
- 16:45:46 [nigel]
- rrsagent, excuse us
- 16:45:46 [RRSAgent]
- I see no action items