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