Meeting minutes
This meeting
Agenda
Nigel: Brief update on IMSC HRM, then DAPT issues and PRs
… Is there any other business?
(nothing)
IMSC HRM
Nigel: Since we last met, some things have happened
… We agreed the proposal to request transition to PR
… Atsushi raised a transition request, which I reviewed
… We hadn't included the correct wording in SotD to make it an updateable Recommendation
… This allows us to add features once it's a Rec. Those still need review and implementation before adding to the Rec
… But useful to wider industry to track new features and their status
… I raised a CfC to make that change, there were no objections
… Atsushi amended the transition request
… Will that be looked at tomorrow?
Atsushi: I believe so, it's in the queue
… will be reviewed shortly
Nigel: So it's now for the team to review the transition request and start the AC review
… The only other part is adding publication dates, which Pierre did. So all good.
Nigel: Anything else on IMSC HRM?
(nothing)
DAPT
Updates since previous call
Nigel: Done some work on DAPT in the last weeks. 7 issues closed, 6 PRs merged, one abandoned as no longer needed
… So we're down to 31 issues, just need to keep the momentum going
… Links in the agenda to the open issues and PR
Nigel: We have 4 issues labeled as agenda
APA WG feedback - name looks like a typo for ADAPT w3c/dapt#167
github: w3c/
Nigel: This issue is APA WG feedback. They have an initiative called "ADAPT", where DAPT looks like a typo for that, also they pronounce it similarly
… It's not a substantive issue, we discussed with the APA WG chairs at TPAC, the sense of that was that they weren't too concerned
… So propose closing it with no change
… Any objections to doing nothing with this?
(nothing)
Nigel: OK, so the group agrees to closing with no change
Consider restricting the metadata vocabulary that is permitted in DAPT w3c/dapt#176
github: w3c/
Cyril: I think the jist of my comment is, for everything we have in the spec will require work, conformance, implementation, testing
… So I'm inclined to make the required features as small as possible
… Agree that title and copyright don't hurt, people will know what to do with them
… Could settle to have guidance for implementers on what to do with them
… Don't know if we have other elements that could be present and should be ignored?
Nigel: Item, title, and copyright are the elements we don't have yet
… ttm:role? Do we use that?
Cyril: We did initially, but I don't think so now
Nigel: Item is possibly the most complicated
Cyril: It's related to extensibility. I think we should say more than we do now. We could say other metadata vocabulary from TTML2 may be present but may be ignored
Nigel: We already say it. In 5.2 we talk about foreign elements
… There's an editor's note about presentation processors
Cyril: It doesn't say for an element and attributes
Nigel: In 5.2.1, says additional vocabulary may be included. So we've already permitted it but without saying about potential use of it
… I agree we could rename 5.2 to make it clear it's not just foreign, any unspecified elements or attributes
Cyril: I think we should give guidance on processing
… I don't want to have people digging into the TTML spec to fully understand what a transformation processor is
Nigel: A few potential actions: One is to describe the purpose of title and copyright and say you can put them in (particularly copyright, not sure about title)
… Next is to rename section 5.2, so it relates to any unspecified elements or attributes
… Or reword sentences about transformation process to make it more obvious what's meant
… Wording for a presentation processor is it may ignore vocabulary it doesn't understand and where DAPT doesn't require support for it
Cyril: We don't say anything about the dapt namespace? An existing processor could see new vocabulary. We want deterministic behaviour for the future
… We have language about namespaces being extensible or reserved for future standardisation
… Want to say that implementations should ignore elements or attributes they don't recognise
Nigel: We have in 5.2 about preserving whenever possible
Cyril: Does it cover daptm namespace also?
Nigel: We could change the name of 5.2 to unrecognised elements or attributes
Cyril: I agree, but make it clear it's also about daptm, foreign namespaces, and add a note about it being an extensiblity point
Nigel: Are there are other use cases for extensibility we want to cover?
Cyril: We should think about elements, attributes, attribute values, text content (character data in general)
Nigel: Anyone else with experience with this kind of extensibility to share?
(nothing)
Nigel: We would want existing implementations not to break on documents that include vocabulary not yet defined
… And future implementations still be able to deal with v1 documents
… Ideally, but not sure the first of those is always possible
… Of those potential actions I listed, do we want to do all of them?
Nigel: 1, specify title and copyright
Cyril: Could be a note, doesn't have to be normative
Nigel: So it's not part of the data model?
Cyril: I wouldn't make it so as it's not directly related to processing of the content
Nigel: Makes sense to add a note
… 2, rename section 5.2 to Unrecognised elements and attributes
… 3, change the editor's note to say presentation processors may ignore where DAPT doesn't require support for it
… 4, be explicit about the set of namespaces and that this is an extensibility point
Cyril: I think that's a good outcome for this issue
Nigel: I agree. If we do that, we should resolve #110 at the same time
Cyril: Do we need to say anything about attribute values?
… As an example, if we want to add a value to an attribute and we don't have a registry
Nigel: Registries aren't allowed to have normative semantics
Cyril: Example, a new script-type value. How to deal with it in an implementation, as it's the value that would be unrecognised
… IME, a way you'd do it is to pick the closest existing value
… Don't want to close the extensibility issue now, we need to think about unrecognised attribute values more
Nigel: Anything else to say on this?
Cyril: No
SUMMARY: Clarify specification to address points discussed above.
Following #191 make workflow type a registry, or remove it? w3c/dapt#194
github: w3c/
Matt: Want to avoid people down the process that the data was created for a single purpose
Nigel: Original transcripts could be used as a source of subtitles or dubbing, so forcing into a particular workflow not helpful
Matt: Yes, what you do with it is your choice
Nigel: I think we have consensus to remove daptm:workflowType
Cyril: Discussion about adding restrictions based on Workflow Type. If you know it's a dubbing document you can validate there's no audio elements in it.
… Not saying I disagree with removing workflow types, but would still want an annotation that you can expect something specific from the document
… If we remove it, would we add another vocabulary, e.g., under 'represents'
Nigel: Yes
Cyril: So the proposal is to replace workflow type with something about what the content represents rather than what it was made for
… Early on, we discussed ttm:role for this
Nigel: Could have multiple role values, and assign a mapping. If the role is description it's what's in the video image, if role is dialog, or music, or sound... Other things there that could be useful
… But ttm:role has both dialog and transcription. It's a flexible value set, but not clear which one should use
Cyril: Still hesitant. Not sure if we should add a new attribute or use the existing one
… We discussed using EBU TT-D vocabulary
EBU-TT Content Type Classification Scheme
Nigel: The content type is similar to what we have now
… So it would reproduce the existing issue we have with workflow type
Cyril: Maybe we should work on a PR and iterate on that?
Nigel: OK, yes
… Another option is to use ttm:item and a name, and a namespace for the values. But would take a lot of space in the document...
Cyril: Could allow an empty value, or make workflow type optional. Or make it a registry, so anyone can register a new value
Nigel: But that doesn't get rid of the problem with workflow type
… Let's make a PR, see how it looks
… Question about whether it should be a registry. Nothing depends on it right now
… Note about whether things are on screen or not, but no normative language
Cyril: Let's work on the PR
SUMMARY: Prepare a Pull Request removing Workflow Type and adding "represents" or similar.
Consider renaming "Default Language" to e.g. "Language" w3c/dapt#204
github: w3c/
Cyril: In the text object, it says language not default language
Nigel: It's optional in the text object, but mandatory in the script object
… I don't feel strongly about this
Cyril: I'm fine, we can close this. Things have changed since last discussed
Nigel: Works for me. Any other views?
(none)
SUMMARY: Close without change
clarify what spans are possible in a text and how they are handled w3c/dapt#158
github: w3c/
Cyril: Should we go back to the original wording?
Nigel: Any recommendations for forms of words would be welcome!
Cyril: I looked at the original issue #17, the recommendations were different to what we landed with
… It was about spans with specific timing, so a different issue
Nigel: The PR does include spans with timing, does address that issue
… But it also adds something about text of script events
… We discussed back in June
Cyril: I think its because we're trying to define what text content means
… I fear we're going into a spiral of adding more
… I can try to add spans in metadata or foreign elements are not considered
SUMMARY: @cconcolato to attempt a further edit
Meeting close
Nigel: Thank you all for participating. We meet in 2 weeks time, on 29 February
(adjourned)