Meeting minutes
This meeting
Nigel: Today we have IMSC-HRM AC Review of PR,
… and DAPT issues and pull requests.
… Any other business, or points to make sure we get to?
no other business
IMSC-HRM AC Review of PR
Nigel: [summarises results]
… The poll closes today
… I think there have been some attempts to get more responses, from various people,
… so thank you for that.
… From what I can see, it appears to be a formality to move to Rec from this, as it stands.
… Obviously we don't have Atsushi to speak for the team.
DAPT
Nigel: I've been busy since last call, and we should take a look.
DAPT issues labelled for agenda
Changing workflowType to alternativeFor
github: w3c/
Replace workflowType with alternativeFor w3c/dapt#217
Nigel: Related issue:
Support within workflowType for generic script origination w3c/dapt#169
Nigel: The problem we had was that workflowType, being restricted to audioDescription or dubbing,
… didn't actually work all that well for everyone in the chain.
… For example it didn't cover things like production of a transcript and/or translation
… with the intent of using it for subtitles.
… So I replaced it with alternativeFor, which is a description of which components of the related media
… the document contents represent, or are an alternative for.
… It's a comma separated list, with four possible values in the list.
… Those are dialogue, nonDialogueSounds, visualNonText and visualText.
… Very few other changes were needed.
… Two questions from me:
… 1. Since nothing depends on this list, at present, should the values come from a Registry Table?
… 2. Should we keep this as a mandatory attribute, or can it be optional?
Cyril: I don't disagree with how it's done.
… Wondering if the term "alternativeFor" is the right term. I think we had "represents" before.
… Why this choice?
Nigel: Yes, I thought someone didn't like "represents", maybe you Cyril?!
… Also, I wanted to tie it in with accessibility language and terminology a bit more closely,
… so that people in that world are comfortable with what this is doing.
… I don't mind changing it to a different name.
Andreas: When I read the term, I was wondering what it means too - it's not intuitive.
… If we go in this direction, "represents" as a term is more accessible.
… Also, in the approach, I see the benefit of it, and the goal to separate the different uses more clearly.
… But it kind of breaks with terms used in the industry like dubbing and audio description.
… For that, they need to get their head around it. That's my first impression.
Nigel: I did add a note about typical values for those use cases but I get what you mean.
Cyril: As you indicated, "alternative" is a key word for accessibility. I need to think about it.
… I'm not sure a transcript is really an alternative - is the transcript used to produce dubbing or AD really an alternative?
Nigel: I'm not glued to this - I've explained my reasoning, but the reasons aren't strong.
Cyril: Regarding the question about registry, I'm not sure.
… It's good for implementation and extensibility to use a registry.
… But the way you've structured the keywords, it feels like it covers the entire space,
… with the union representing everything.
Nigel: Maybe, but there could be something else.
Cyril: You might want more granularity - text could be signs, time and dates etc.
… So now I think about it, using a registry is better probably.
Nigel: OK
Cyril: The last question was about making it optional vs mandatory.
… What is the use case where you wouldn't know what your script represents?
… It may evolve, but at any point in time you should know what the script represents.
… so I still think it should be mandatory.
Nigel: I'm happy to take the action to turn the content-descriptor values into a Registry Table.
… The other possible action is renaming it to "represents" or some other thing.
Cyril: [reads the original issue] I don't think I have a problem with "represents"
Nigel: OK, any other thoughts before I give myself the action to change it?
no other comments
SUMMARY: @nigelmegitt Change `<content-descriptor>` to be a Registry Table; change name to "represents".
Add informative section about mapping from TTML to the DAPT data model w3c/dapt#216
github: w3c/
Nigel: Quite a big change, new informative section added, mostly as discussed in the issue and our previous call.
… Introduces some implementation considerations for ingesting generic TTML2 documents that are also
… DAPT conformant, which might not have a 1:1 mapping to the DAPT Data Model.
… My biggest question is: is there anything in here that anyone thinks needs to be normative?
Cyril: Thank you for this, I started to review it, and that was my biggest question.
… You phrased it that there is no requirement for DAPT implementations to perform the task...
… which is what? Parsing the DAPT document into a DAPT Data Model?
Nigel: It's "attempting to populate a data structure corresponding to the DAPT data model from any conformant DAPT document"
Cyril: Why isn't that a requirement?
Nigel: Because the only normative requirement is that a processor conforming to the TTML2 profile can process
… the document.
Andreas: But a DAPT processor should be able to do it?
Nigel: That's not a thing though, a "DAPT processor"
Andreas: You ask if there's any concern about making this informative, and I think I mentioned in the last
… call that I have some questions about whether that's enough.
… My simple thinking: 2 implementations that implement DAPT, are DAPT implementations.
… If they're parsing DAPT-conformant TTML documents they should have the same result,
… so that there's interoperability. If you leave this open to be implementation dependent,
… that could be a problem. Could they come up with different results?
… This would be my main question when I come to review it.
Nigel: The reason I don't think that's a problem is because the semantics for processing the document
… are normatively defined by TTML2.
… Where we might need something normative would be if we wanted to have a fixed mapping back from
… every possible DAPT conformant document into the DAPT data model.
… Because that data model is defined by this spec, there can't be normative requirements for doing that within TTML.
Andreas: Again, maybe it's simple how I'm thinking, but a possible implementation would be to make the DAPT
… data model the internal data model, and handle the document accordingly.
… If two implementations do this I would assume they come up with the same values.
Cyril: I'm wondering what are the classes of TTML processor that could do something meaningful with
… a DAPT document. For example if I have a TTML authoring tool and I load a DAPT document,
… I don't think the generic tool would be able to do any edits and guarantee that the output would
… remain conformant with the profile. Are you thinking that a generic authoring tool would see what is
… permitted or prohibited and constrain its UI to do only what's permitted?
… The bigger question: yes, a DAPT document is a TTML document, but is that useful for having a TTML
… processor process the document. I think we need tailored DAPT processors.
… They will do meaningful edits to the document.
… Just knowing they are TTML documents does not seem to be sufficient to do meaningful edits.
Nigel: A generic TTML2 presentation processor that supports audio features should be able to
… play back a DAPT audio description script for example.
… A generic TTML2 transformation processor can observe the profile feature and extension requirements
… and decide if it supports the required features or not, and if it doesn't, presumably all bets are off, in terms of
… what it does.
… My thinking is that the profile constraints manage this for us.
Cyril: On the playback side, I agree.
… A generic TTML processor could present a DAPT document without knowing about the DAPT data model, for sure.
… For a generic TTML transformation processor, that seems like a theoretical concept, so I wouldn't worry about these.
… So I think we should introduce a DAPT processor, which does not necessarily support generic TTML processing,
… but does support DAPT Data model processing.
… Then that section that you wrote can have SHALL statements that only apply to this class of processor.
Nigel: This is for validators, or editors?
… I have another concern, which is extensibility of DAPT, and forwards/backwards compatibility.
… If we do as you suggest Cyril, how do we avoid introducing compatibility issues in the future?
Cyril: Can you repeat the example?
Nigel: If we introduce a new entity into the data model in the future, for example. E.g. a Script Event grouping
… structure. Wouldn't that break this new class of DAPT processor?
Cyril: Generically, if we define a new entity that does not exist today at all, the old data model processors
… would ignore it, but the grouping one is a special case - I think that's what you've done, to identify
… what is a script event wherever it is in the document.
Nigel: I think the answer will hinge on whether we really need a DAPT processor class.
… It would be helpful to get review comments on the pull request.
Cyril: When I looked at your example, today we seem to rely on the xml:id to decide if a div might be a
… Script Event. I wonder if we should have a ttm:role that says "script event" more explicitly.
… Then the DAPT processor just finds this, and that's it.
… How deeply nested in the TTML shouldn't matter.
… Other things can be pruned.
… You do whatever you want with the rest. That seems simpler to me.
Nigel: If we do that then we need structural constraints, that we currently don't list.
… For example what if a div marked as a Script Event contains another div marked as a Script Event.
Cyril: Yes, we could have constraints about that.
Nigel: Yes, that's an option.
… My overall direction here is steered by "less is more", and if we don't need a DAPT Processor, say,
… then we shouldn't create one. Of course maybe it is actually important, and we should define it.
Cyril: The original question is what a processor should do if it encounters a DAPT document with
… contents that go beyond what would get directly made by a mapping from this version's DAPT Data Model.
Nigel: Yes.
SUMMARY: Reviews to continue, revisit this after more thought and discussion.
Other Pull requests
Nigel: I opened two more pull requests, one to add at-risk features, the other to
… define empty Text and note the use case for omitting Text objects.
… I see they've recently been approved - thank you!
Next meeting - time will be adjusted
Nigel: Next meeting, and going forwards until next DST switch, the UTC time of the call will be adjusted
… to be an hour earlier, as previously discussed. Back to the "usual" local time, except in places without DST.
Meeting close
Nigel: Thanks everyone, we're just about at time. [adjourns meeting]