- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 15 Feb 2024 17:28:40 +0000
- To: "public-tt@w3.org" <public-tt@w3.org>
- Message-ID: <61F0744A-A64B-4781-A2A5-2A3D1CEE1AC1@bbc.co.uk>
Thanks all for attending today’s TTWG call. Minutes can be found in HTML format at https://www.w3.org/2024/02/15-tt-minutes.html
In plain text:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
15 February 2024
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2024/01/18-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/275
[4] https://www.w3.org/2024/02/15-tt-irc
Attendees
Present
Atsushi, Chris, Chris_Needham, Cyril, Gary, Matt, Nigel,
Pierre
Regrets
Andreas
Chair
Gary, Nigel
Scribe
cpn, nigel
Contents
1. [5]This meeting
1. [6]Agenda
2. [7]IMSC HRM
3. [8]DAPT
1. [9]Updates since previous call
2. [10]APA WG feedback - name looks like a typo for ADAPT
w3c/dapt#167
3. [11]Consider restricting the metadata vocabulary that
is permitted in DAPT w3c/dapt#176
4. [12]Following #191 make workflow type a registry, or
remove it? w3c/dapt#194
5. [13]Consider renaming "Default Language" to e.g.
"Language" w3c/dapt#204
6. [14]clarify what spans are possible in a text and how
they are handled w3c/dapt#158
4. [15]Meeting close
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 [16]w3c/dapt#167
[16] https://github.com/w3c/dapt/issues/167
github: [17]w3c/dapt#167
[17] https://github.com/w3c/dapt/issues/167
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 [18]w3c/dapt#176
[18] https://github.com/w3c/dapt/issues/176
github: [19]w3c/dapt#176
[19] https://github.com/w3c/dapt/issues/176
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?
[20]w3c/dapt#194
[20] https://github.com/w3c/dapt/issues/194
github: [21]w3c/dapt#194
[21] https://github.com/w3c/dapt/issues/194
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
[22]EBU-TT Content Type Classification Scheme
[22] https://www.ebu.ch/metadata/cs/EBU-TTContentTypeCS.xml
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"
[23]w3c/dapt#204
[23] https://github.com/w3c/dapt/issues/204
github: [24]w3c/dapt#204
[24] https://github.com/w3c/dapt/issues/204
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
[25]w3c/dapt#158
[25] https://github.com/w3c/dapt/issues/158
github: [26]w3c/dapt#158
[26] https://github.com/w3c/dapt/pull/158
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)
Minutes manually created (not a transcript), formatted by
[27]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).
[27] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 15 February 2024 17:28:57 UTC