Meeting minutes
This meeting
Nigel: Today we have a DAPT pull request,
… a TTML2 ttm:role issue,
… TPAC and one AOB so far: TTML in MP4 MPEG issue
… Is there any other "other business" to cover today?
no other business
DAPT
Nigel: There's one issue on the agenda
Add section about mapping from TTML to the DAPT data model w3c/dapt#216
github: w3c/
Nigel: Thank you Cyril for all the review comments.
… I tried to resolve them but left this on the agenda so we could cover the questions that arose.
Nigel: Re the Script Event identification, thanks for raising the issue.
… Can we tackle it as a separate pull request?
Cyril: I'm not sure, we may need to do it first because it could simplify the algorithm
… for identifying Script Events and make this pull request simpler.
Nigel: I think my preference would be to finish this one before iterating over it again.
… There's a lot more in this pull request than just that bit.
… If we end up changing the algorithm significantly I don't really mind, but at least we would have
… a logical development based on what we have now.
… Is that ok?
Cyril: Let's see, I need to do a re-review following the recent changes.
… Regarding DAPTv2 and extensibility, we say today that every DAPT document must write
… the DAPT 1.0 content profile designator, which is a promise on all the future profiles we may generate,
… and we're doing that for backwards compatibility in the future.
… I'm not sure if we can hold that promise forever.
Nigel: Me neither
Cyril: My point was that "a profile compliant to this specification" without mentioning the profile version,
… could be reworded so it doesn't need to change, a DAPT content profile designator
… rather than forcing the v1.0 designator.
Nigel: That makes sense, please could you highlight where you mean and put a comment about it in the thread?
Cyril: I'll add that so we don't lose this thought.
Nigel: The next one is the additional validation steps, should I add a hypothetical example?
Pierre: Wasn't the original issue non-pruning of unsupported vocabulary?
Nigel: Right, this PR brings in the idea that stuff must be pruned everywhere outside metadata.
Pierre: Then there should be a corollary that metadata elements should not include metadata derived from
… the document content, or temporal metadata.
… We should cast a wide net, to strongly discourage people from getting into this trouble, which
… is not solvable really.
… My suggestion is, instead of recommending what a downstream processor should do,
… if it encounters a document that contains vocabulary that belongs to a profile that is not signalled,
… to recommend in the first place that metadata that would cause that situation should not be used.
Nigel: That's no problem, we can do that.
Cyril: I wonder if we shouldn't be more precise in terms of what types of processor we are talking about.
… I.e. presentation processor behaviour, transformation processor behaviour, validation processor behaviour etc.
… Here, if it's a presentation processor, saying SHOULD NOT implement is sufficient.
… If it's a validation processor then you prune vocabulary that is not declared in the signalled profile,
… so this paragraph is not applicable.
… it's only applicable to transformation processors, right? Validation and presentation processors don't fix anything.
<MattS> apols - I have to head to another meeting...
Nigel: Processors don't have to be exactly in one class, so we can't make opposing rules for a processor
… that is both a transformation and a validation processor.
Cyril: If it's doing validation, then these rules apply?
… If it said "taking steps to fix" the document I would be okay with that
… If you meant that a validation processor might take extra steps to validate those features if it wants to,
… maybe, yes, it's a permission as you said.
… The sentence seems to be mixing the two parts.
Nigel: Okay. I've got a clearer handle on the problem here, and a couple of actions.
… Next one is about processors SHOULD NOT implement support for features that the document
… does not claim conformance to.
Cyril: We should not require implementers to model features.
Nigel: Should we be clear we mean non DAPT profiles?
Cyril: You can just know that your implementation supports each thing, without modelling features.
Nigel: Exactly.
… The implementer can be aware of the features without writing software that explicitly models them.
Cyril: I'll read this again. The term feature could be interpreted loosely, it does not have to be something
… defined in a profile definition.
Nigel: Right, yes.
Cyril: If it were treated as an "attribute" rather than a "feature" then I see.
… I guess this is probably fine, let me review it again.
Nigel: next is nested divs.
Cyril: [suggests allowing a relaxed TTML representation that can have nested divs]
… In the spec we don't say you cannot have Script Events inside other div elements
… The xpath for Character, say, is really explicit, but it is not for Script Event.
… I'm fine with having a section that says how to go from XML to the Data Model,
… and the section you wrote is fine in spirit, but we don't give permission to writers to do it, or it is implicit.
Nigel: The easy way out is to define a generic grouping structure.
Pierre: Or you could forbid it, I would, if there are no semantics for it in the DAPT data model.
Cyril: But then it means in the future we cannot bring grouping in, because a v2 document would not be
… a compliant v1 document. That's what we're trying to avoid.
Pierre: That's true. At some point data models have to have a scope.
… Is there any conceivable reason for a script to be contained in another script?
Cyril: No, but other grouping could be possible.
Pierre: You could put grouping semantics in via other mechanisms, like a group attribute.
… That's more flexible because one script can be in multiple groups.
… Unless the semantic is super strong then you don't need such tight binding.
Pierre: You could say only terminal divs are Script Events
Cyril: That's the issue I opened this morning, that Script Events are identified more clearly.
Pierre: You're making v1 implementations more complex for a hypothetical future.
Cyril: You're right.
Pierre: Even in TTML2, a TTML2 doc is a valid TTML1 doc technically, but the outcome is never going to be good.
… e.g. ruby - so too flexible is not always practically interesting.
Cyril: This was the design philosophy, that DAPT should be as simple as it can be.
… Maybe what Pierre is saying is the way forward.
Nigel: Maybe - I do think there are semantics for divs in the future that would be interesting, like shifting timings.
Pierre: It could mean that a v1 processor would reject a v2 document
… In many use cases that's actually a good thing
SUMMARY: Useful discussion, some ways forward, more thought and review needed
TPAC 2024
Nigel: TPAC registration is open
Nigel: The schedule has us with some meetings on the Monday and others on the Friday.
… Let me know if you think we should ask the organisers to shuffle the schedule to accommodate any needs.
Cyril: Do we need the Friday as a full meeting, or could we ask to move to the Tuesday?
Nigel: Maybe
Cyril: Just an option
Nigel: That's for me and Gary to check over and sort out
Cyril: A page where we put who is coming or not would be useful
Atsushi: I will be there
… Please don't forget to register as early as possible. The price increases if you're late!
TTML in MP4 MPEG issue
Use of edit lists and timed text tracks MPEGGroup/FileFormat#40
Cyril: The spec has some gaps about edit lists.
… It could mean different things to use edit lists, leading to different results, unless we do something.
… I think the text at the beginning tries to be clear enough, it's an old issue.
… I'm trying to see if there's momentum to move clarification forward.
… If you care about TTML in MP4 please express your opinion in the issue.
… I know Nigel did in the past.
Nigel: I commented in some detail
… Others agreed, so there's some feedback
Cyril: MPEG is working in July, so it is possible that we draft a change to this text.
Nigel: Thank you for reminding us about this
Meeting close
Nigel: We've gone over time, thank you very much everyone. [adjourns meeting]