IRC log of tt on 2024-04-11
Timestamps are in UTC.
- 15:01:22 [RRSAgent]
- RRSAgent has joined #tt
- 15:01:27 [RRSAgent]
- logging to https://www.w3.org/2024/04/11-tt-irc
- 15:01:27 [Zakim]
- RRSAgent, make logs Public
- 15:01:28 [Zakim]
- Meeting: Timed Text Working Group Teleconference
- 15:01:33 [nigel]
- Agenda: https://github.com/w3c/ttwg/issues/279
- 15:01:40 [nigel]
- Previous meeting: https://www.w3.org/2024/03/28-tt-minutes.html
- 15:01:43 [nigel]
- scribe: nigel
- 15:01:58 [nigel]
- Present: Atsushi, Nigel, Pierre
- 15:02:38 [nigel]
- Present+ Gary
- 15:02:46 [nigel]
- Chair: Gary, Nigel
- 15:02:54 [nigel]
- Present+ Matt
- 15:03:09 [nigel]
- Topic: This meeting
- 15:03:50 [nigel]
- Nigel: Today we have IMSC-HRM and a couple of pull requests on DAPT.
- 15:04:07 [nigel]
- .. Anything else for the agenda, or points to make sure we get to?
- 15:04:19 [nigel]
- Present+ Cyril
- 15:04:50 [nigel]
- Cyril: AOB - NAB is coming and we're organising an event we can mention
- 15:04:53 [nigel]
- Nigel: Thank you
- 15:05:07 [nigel]
- Topic: IMSC-HRM
- 15:05:36 [nigel]
- Nigel: The AC Review poll closed, no objections.
- 15:05:55 [nigel]
- .. I think we need a pull request to address the proposed changes?
- 15:06:37 [nigel]
- Atsushi: Yes. I believe we are waiting. Once the pull request is raised and all comments are satisfied
- 15:07:00 [nigel]
- .. we can go to publication. The changes are just suggestions and are all editorial,
- 15:07:12 [nigel]
- .. so it would be possible to go directly to Rec but it would be better to deal with the suggestions and comments.
- 15:07:35 [nigel]
- Nigel: Pierre, are you okay to open a pull request for those?
- 15:07:49 [nigel]
- -> https://github.com/w3c/imsc-hrm/issues/79 A few minor editorial suggestions w3c/imsc-hrm#79
- 15:08:03 [nigel]
- Pierre: I was just waiting to make sure there were no other comments.
- 15:08:11 [nigel]
- .. I will prepare the pull request straight away.
- 15:08:15 [nigel]
- Nigel: Thank you.
- 15:08:22 [nigel]
- .. Anything else to say about this?
- 15:08:38 [nigel]
- nothing more
- 15:08:45 [nigel]
- Topic: DAPT
- 15:09:16 [nigel]
- -> https://github.com/w3c/dapt/labels/agenda Issues labelled "agenda"
- 15:10:05 [nigel]
- Nigel: We discussed these two last time but there were no concrete actions,
- 15:10:19 [nigel]
- .. and we said we would continue the discussion on the pull requests, but we didn't actually do that,
- 15:10:26 [nigel]
- .. so I put them back on the agenda. Hope that's ok!
- 15:11:26 [nigel]
- Subtopic: Replace workflowType with represents w3c/dapt#217
- 15:11:36 [nigel]
- github: https://github.com/w3c/dapt/pull/217
- 15:12:07 [nigel]
- Matt: Apologies, I didn't notice anything coming through to me for the review request.
- 15:13:08 [nigel]
- Nigel: This is about replacing workflowType with represents as a list of the content types that
- 15:13:11 [nigel]
- .. the document represents.
- 15:13:30 [nigel]
- .. Last time we talked we agreed to make the <content-descriptor> into a Registry Table,
- 15:13:35 [nigel]
- .. and I made that change after the call.
- 15:14:18 [nigel]
- .. We also had it as "alternativeFor" last time and had agreed to change that into "represents" which I also did.
- 15:15:31 [nigel]
- Matt: [recalls the discussion, agrees with the intent]
- 15:15:49 [nigel]
- Nigel: The question for me now is do I go ahead and merge now or wait for a review and
- 15:15:54 [nigel]
- .. take appropriate response on the basis of that.
- 15:16:01 [nigel]
- Matt: I feel I need to read it.
- 15:16:19 [nigel]
- Cyril: I don't have any change to my pull request approval.
- 15:17:06 [nigel]
- .. Just wondering about the granularity of the "represents", could we use represents on Script Events?
- 15:17:14 [nigel]
- Nigel: Further down the tree?
- 15:17:27 [nigel]
- Cyril: Yes, if you want to know which Script Events actually correspond to each type, we already have
- 15:17:41 [nigel]
- .. Script Event Description which is human readable, and we have Script Event Type that has a Registry,
- 15:17:56 [nigel]
- .. but the values don't align - we have dialogue, spoken text, on screen text...
- 15:19:06 [nigel]
- Nigel: Ooh I hadn't thought of that. Looking at it, I agree, it seems like this could be one list.
- 15:19:51 [nigel]
- Matt: I'm happy with the general approach.
- 15:20:51 [nigel]
- Cyril: I'm thinking - if you were to replace the values of represents by the values of Script Event Type...
- 15:21:08 [nigel]
- .. If you made a set of the Script Event Types in the document, would that work?
- 15:21:36 [pal]
- pal has joined #tt
- 15:22:13 [nigel]
- Nigel: I see 3 options.
- 15:22:31 [nigel]
- .. 1. What you said Cyril, allow the event type values to be coalesced into represents at the document level.
- 15:23:22 [nigel]
- .. 2. Add a mapping from event type into a simpler smaller set of represents values, e.g. title and OnScreenText in event type
- 15:23:31 [nigel]
- .. both map to visualText in represents.
- 15:24:06 [nigel]
- .. 3. Replace eventType with represents and use the same registry table for both.
- 15:24:24 [nigel]
- .. The nuance is that represents allows a list, whereas eventType maybe should be a single value.
- 15:25:00 [nigel]
- Cyril: Sorry I only noticed this now. Also the registry table for script event type needs some descriptions.
- 15:25:13 [nigel]
- .. I like the idea of the column for mapping to represents.
- 15:25:41 [nigel]
- .. I was wondering what the point of spokenText is?
- 15:25:56 [nigel]
- Nigel: We spent no time looking at the registry table values for event type, they're just example values.
- 15:26:07 [nigel]
- Cyril: I agree those are the three options, I don't have a strong view.
- 15:26:23 [nigel]
- .. You may not want the same granularity of description at the document level as at the script event type.
- 15:26:34 [nigel]
- Nigel: That's why I was thinking of the mapping idea.
- 15:27:16 [nigel]
- .. I think that if we want to do the mapping, that would be a new issue and pull request.
- 15:27:32 [nigel]
- Cyril: A 4th option is to not have the document level summary at all but inspect the document contents
- 15:27:35 [nigel]
- .. to see what it contains.
- 15:27:47 [nigel]
- Nigel: That's true, but...
- 15:28:03 [nigel]
- Cyril: In the workflow you want an early indication of the potential uses of the document.
- 15:28:14 [nigel]
- Nigel: So you're arguing against that previous point?!
- 15:28:26 [nigel]
- Cyril: Yes, I just wanted to note the possibility in case we want to come back to this in the future.
- 15:28:51 [nigel]
- Nigel: What to do?
- 15:28:53 [nigel]
- .. Options:
- 15:29:15 [nigel]
- .. 1. Merge now and open a separate issue and pull request to deal with mapping from script event type to represents
- 15:29:33 [nigel]
- .. 2. Go round the loop one more time and try to fix this up before merging
- 15:29:49 [nigel]
- .. 3. Merge now and do nothing about script event type for the time being.
- 15:30:17 [nigel]
- .. By the way we will need to come back to all the Registry Tables at some point to make sue
- 15:30:27 [nigel]
- .. they have the right values. All of the entries are Provisional right now.
- 15:30:30 [nigel]
- s/sue/sure
- 15:30:45 [nigel]
- .. Any preferences?
- 15:30:54 [nigel]
- .. My preference is to merge now and then incrementally improve.
- 15:31:01 [nigel]
- Cyril: We should have an issue that tracks it then.
- 15:31:28 [nigel]
- Nigel: Do you want to open that then?
- 15:31:35 [nigel]
- Cyril: Doing it now.
- 15:31:56 [nigel]
- Matt: Apologies, got to run to another meeting, please prod me if there's any more review needed. Apologies again for not noticing this one.
- 15:32:02 [nigel]
- Matt leaves
- 15:32:49 [nigel]
- SUMMARY: Merge pull request, deal with script event type and represents in a separate issue
- 15:33:16 [nigel]
- Subtopic: Add informative section about mapping from TTML to the DAPT data model w3c/dapt#216
- 15:33:25 [nigel]
- github: https://github.com/w3c/dapt/pull/216
- 15:35:19 [nigel]
- Nigel: From last time, I think the determining factor is if we need a class of DAPT implementation
- 15:35:34 [nigel]
- .. that maps from TTML2 into the DAPT data model. If we do, that means we need to make these
- 15:35:40 [nigel]
- .. provisions normative.
- 15:35:58 [nigel]
- Cyril: Taking a step back, we did this pull request to cover the case that there is a document that
- 15:36:08 [nigel]
- .. conforms to the profile but does not map directly to the DAPT data model.
- 15:36:28 [nigel]
- .. In practice if you have an implementation of DAPT that is "just" DAPT, which I think will be the majority case,
- 15:36:57 [nigel]
- .. then this situation should not happen. You shouldn't end up with a document that cannot be easily mapped.
- 15:37:03 [nigel]
- Nigel: Yes, to a point.
- 15:37:33 [nigel]
- .. The exception could be from the compatibility perspective - some future version of DAPT adds in a feature
- 15:37:42 [nigel]
- .. that we want older DAPT processors to handle gracefully.
- 15:37:53 [nigel]
- .. It's not just about TTML2 generically.
- 15:37:56 [nigel]
- Cyril: You're right.
- 15:38:28 [nigel]
- .. Thinking out loud, if we added constraints like feature extensions to restrict a DAPT document
- 15:38:41 [nigel]
- .. to correspond only to the DAPT data model, what would be the problem? Extensibility?
- 15:38:47 [nigel]
- Nigel: Yes, that would be the main one.
- 15:39:12 [nigel]
- .. It's really the structural issue of divs containing other divs or mixed div and p children.
- 15:39:23 [nigel]
- .. Which we agreed there could be a future use for.
- 15:39:46 [nigel]
- .. If we prohibited that then we wouldn't be able to use that capability in the future without making a
- 15:39:50 [nigel]
- .. breaking version change to DAPT.
- 15:40:34 [nigel]
- .. Maybe we could argue that, to make sure that conformant implementations can deal with those changes,
- 15:40:42 [nigel]
- .. that's why we need to make the informative provisions normative.
- 15:41:01 [nigel]
- Cyril: What about text content anywhere other than p and span?
- 15:41:13 [nigel]
- Nigel: It's allowed in p and span but TTML doesn't allow it anywhere else.
- 15:41:21 [nigel]
- .. Except for metadata elements etc, of course.
- 15:41:25 [nigel]
- Cyril: Ok, thank you.
- 15:42:38 [nigel]
- Nigel: Does that argument about future compat seem correct?
- 15:42:50 [nigel]
- Cyril: Yes. In general I prefer something normative otherwise there won't be interoperability.
- 15:43:08 [nigel]
- .. Does this mean we need a DAPT processor type?
- 15:43:12 [nigel]
- Nigel: No I don't think it does.
- 15:47:39 [nigel]
- Cyril: In §7.2 it defines a DAPT Processor in terms of conformance to the profile provisions and to the document.
- 15:47:50 [nigel]
- .. How would we do that?
- 15:48:04 [nigel]
- Nigel: I'd make extension features referencing the new normative provisions, so it all ties together.
- 15:48:48 [nigel]
- Cyril: I would like to take a stab at re-writing §5 or proposing changes.
- 15:48:55 [nigel]
- Nigel: OK, that's fine, otherwise I'd have done it.
- 15:49:13 [nigel]
- Cyril: Not sure when I'll do it.
- 15:49:26 [nigel]
- Nigel: Why don't I do a first pass, and then you can review it?
- 15:49:47 [nigel]
- Cyril: That's fine.
- 15:50:09 [nigel]
- .. I think we should move the new section 5 to after the Constraints section. We're only concerned
- 15:50:22 [nigel]
- .. with valid documents, which are defined in the Constraints section.
- 15:50:50 [nigel]
- .. I would start by saying that the processing behaviour for a processor processing a valid document that
- 15:50:59 [nigel]
- .. contains additional content not in the DAPT model is the following...
- 15:51:38 [nigel]
- .. Say there may be conformant DAPT docs that contain more, e.g. for a new version, or a round trip through
- 15:51:41 [nigel]
- .. a generic TTML tool.
- 15:51:50 [nigel]
- .. That's how I'd start, by explaining that.
- 15:52:10 [nigel]
- .. Once the context is clear I think it's easier to understand.
- 15:52:56 [nigel]
- Nigel: I think it'll be important to say that the graceful handling feature requirements may be replaced
- 15:53:39 [nigel]
- .. in future versions by something that defines some other behaviour.
- 15:53:45 [nigel]
- Cyril: Did you mention parsing, or just mapping?
- 15:54:01 [nigel]
- Nigel: Just mapping. I think parsing is defined by XML, we're talking about building a data model from the parsed entities.
- 15:54:04 [nigel]
- Cyril: OK
- 15:54:39 [nigel]
- Pierre: Are you going to take the TTML approach of pruning?
- 15:54:39 [nigel]
- Nigel: I don't think so, not quite
- 15:54:41 [nigel]
- Cyril: For validation purposes, yes.
- 15:54:56 [nigel]
- .. But a read/write processor should try to retain unrecognised vocab
- 15:55:11 [nigel]
- Pierre: The reason for mentioning: if the processor sees elements or attributes it does not understand then
- 15:55:23 [nigel]
- .. there's no hope it can understand how to deal with those unknown elements.
- 15:55:42 [nigel]
- .. If you merely preserve them, that doesn't take into account the semantics of the unknown elements.
- 15:55:57 [nigel]
- .. Generally it's not possible unless you specify extension rules such as vocabulary in a particular part of the
- 15:56:10 [nigel]
- .. model does not affect e.g. timing etc.
- 15:56:41 [nigel]
- .. Some things can be preserved with minimal risk, but everything else, it's hopeless.
- 15:57:03 [nigel]
- Cyril: You can have multiple values of profiles in the contentProfiles attribute, but if you write back
- 15:57:17 [nigel]
- .. a file then you shouldn't write back values of contentProfiles that you don't understand.
- 15:57:52 [nigel]
- .. You could end up with semantically incorrect content.
- 15:58:14 [nigel]
- Nigel: Example is an attribute for number of words, doc says 3, editor adds 2, saves the value as 3 because it
- 15:58:17 [nigel]
- .. doesn't understand it.
- 15:58:31 [nigel]
- Pierre: There's a danger of getting rules that are so complex that nobody understands them.
- 15:58:58 [nigel]
- Pierre: The TTML model is blunt but straightforward. Just get rid of everything you don't understand.
- 15:59:10 [nigel]
- .. Maybe some stuff could have been kept, but at least it is predictable.
- 15:59:20 [nigel]
- .. When the author wants the document to be compatible with an older version,
- 15:59:32 [nigel]
- .. do it so that when you strip the newer stuff it's still valid for the older version.
- 16:00:05 [nigel]
- SUMMARY: @nigelmegitt to make edits as discussed, @cconcolato to review, discussion to continue.
- 16:00:48 [nigel]
- Topic: AOB
- 16:01:12 [nigel]
- Cyril: there's an event happening where we're gauging appetite to talk about live captioning,
- 16:01:25 [nigel]
- .. wondering if there's a TTWG view on it. It's on Monday.
- 16:02:12 [nigel]
- Nigel: I don't think I can say anything about this as a Chair because we've not really discussed it in TTWG.
- 16:02:26 [nigel]
- .. But I may be able to say something in my BBC role.
- 16:02:36 [nigel]
- .. Can we take this offline please?
- 16:03:18 [nigel]
- Cyril: Can we add this as an AOB for after the meeting so we can summarise the outcomes?
- 16:03:21 [nigel]
- Nigel: Sounds like a good idea.
- 16:03:26 [nigel]
- Topic: Meeting close
- 16:03:43 [nigel]
- Nigel: We're 3 minutes over, thanks everyone! [adjourns meeting]
- 16:03:55 [nigel]
- rrsagent, make minutes
- 16:03:56 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/04/11-tt-minutes.html nigel
- 16:08:26 [nigel]
- scribeOptions: -final -noEmbedDiagnostics
- 16:08:30 [nigel]
- zakim, end meeting
- 16:08:30 [Zakim]
- As of this point the attendees have been Atsushi, Nigel, Pierre, Gary, Matt, Cyril
- 16:08:32 [Zakim]
- RRSAgent, please draft minutes v2
- 16:08:33 [RRSAgent]
- I have made the request to generate https://www.w3.org/2024/04/11-tt-minutes.html Zakim
- 16:08:39 [Zakim]
- I am happy to have been of service, nigel; please remember to excuse RRSAgent. Goodbye
- 16:08:40 [Zakim]
- Zakim has left #tt
- 16:16:08 [nigel]
- rrsagent, excuse us
- 16:16:08 [RRSAgent]
- I see no action items