- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Fri, 30 Sep 2022 16:18:28 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <AM0PR01MB62573E5F624B6527AE25DC70CA569@AM0PR01MB6257.eurprd01.prod.exchangelabs>
Thanks all for attending yesterdays TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2022/09/29-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
29 September 2022
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2022/09/16-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/228
[4] https://www.w3.org/2022/09/29-tt-irc
Attendees
Present
Atsushi, Cyril, Gary, Nigel, Pierre
Regrets
-
Chair
Gary, Nigel
Scribe
nigel
Contents
1. [5]This meeting
2. [6]TPAC follow-up
3. [7]DAPT issues
1. [8]Should we allow inheritance of xml:lang or require
it to be set explicitly? w3c/dapt#62
2. [9]Do we want to allow inline styles? w3c/dapt#60
3. [10]Consider timing syntax constraints w3c/dapt#59
4. [11]Rechartering status update
5. [12]Rather than using ttm:role for script type, define new
attribute w3c/dapt#54
6. [13]Meeting close
Meeting minutes
This meeting
Gary: Using Teams for the TPAC meetings was good
Nigel: We can switch!
Gary: I wouldn't be opposed.
Nigel: Let's do it.
Gary: I can;t do the next one, in two weeks, it coincides with
Demuxed.
Nigel: Agenda for today is: follow-up opportunity from TPAC,
DAPT issues, Rechartering status update
Anything else for the agenda, or points to make sure we
cover?
Pierre: There's an outstanding pull request on IMSC-HRM I'd
like to encourage folks to review it.
Open 13 days ago, discussed in last meeting. I'd like to
merge it unless there are significant concerns.
Nigel: Thank you for the reminder.
Sounds like there's nothing more to say on that.
Pierre: I plan to merge it if there are no concerns - it
addresses a real issue.
Nigel: Thanks.
TPAC follow-up
Nigel: Nothing specific from me - I just want to give the
opportunity to discuss if there's anything on your mind.
DAPT issues
[14]DAPT Issues marked for the agenda
[14] https://github.com/w3c/dapt/issues?q=is:open+is:issue+label:agenda
Should we allow inheritance of xml:lang or require it to be set
explicitly? w3c/dapt#62
<Github> [15]https://github.com/w3c/dapt/issues/62 : Should we
allow inheritance of xml:lang or require it to be set
explicitly?
[15] https://github.com/w3c/dapt/issues/62
Nigel: The issue here is that the current spec text requires an
explicit xml:lang on tt and every p.
Cyril: Also it's value must not be empty
Some background:
The use cases are:
1. Transcription of a show with multiple languages - it's
important to be able to annotate the actual language
per script event.
2. When you have, for a given event, after it has been
translated, you want to preserve the original
language. You can have 2 or more languages per event, one
being the original, the other being the translation.
I don't have a strong preference, we could live with
inheritance.
The document would be more regular if there is always an
xml:lang on every p.
Inheritance of xml:lang is not complex. It's not like CSS
properties where you need a computed value.
No strong preference, just in the spirit of making it simple.
Are you concerned about the redundancy, the size?
Nigel: Yes, somewhat, especially in the AD case.
But generally I think the formal requirement is that there is
a non-empty computed xml:lang on all
character content. There can be a suggestion of a way of
doing it, but not the formal requirement to have
it on every p element.
Especially early in the workflow, it may well be that the
original language text is all in the document's
xml:lang and adding it everywhere is unnecessary.
Cyril: I agree.
I think you're happy to say that there shall be a non-empty
computed xml:lang on all character content,
and either a recommendation or a permission to put it on
every p, something like that?
Nigel: Yes.
Cyril: Fine with that.
Nigel: Any other views?
SUMMARY: Require non-empty computed xml:lang on all character
content, permit/recommend having it on every p element.
Nigel: It could also be on span elements, by the way, in
principle.
Cyril: I would say the recommendation should be to split per
language.
But you may have one Spanish word in an English sentence,
say, you may want to tag that.
Nigel: Exactly. I'm in favour of flexibility unless a strong
reason to constrain.
Cyril: So you or me will prepare a pull request?
Nigel: Yes, others welcome too!
Do we want to allow inline styles? w3c/dapt#60
<Github> [16]https://github.com/w3c/dapt/issues/60 : Do we want
to allow inline styles?
[16] https://github.com/w3c/dapt/issues/60
Nigel: Is there any reason to disallow inline styles?
Cyril: First thought I had was about Japanese - does it make
sense to have Ruby in AD or Dubbing Scripts,
but if you want it then it has to be on the span level.
I think I would be silent here and let implementations do
what they want.
It's out of scope of our spec. If you have a processor that
doesn't use styles it will ignore them.
If you want to make subtitle files then it's a good idea to
allow them.
Nigel: Yes, they're permitted in IMSC.
Cyril: Yes
Happy to see if you have any wording you want to add.
Nigel: One other use case: for audio mixing, we expect to use
the animate element and that effectively
sets and varies the values of inline style attributes, in
this case things like tta:gain and tta:pan.
So from that point of view it would be complex to prohibit
inline styling.
Cyril: Are they considered inline if they're only on animate?
Nigel: I haven't checked that in detail.
Cyril: On the principle I would prefer to allow it by being
silent. I'm happy to see wording if you
want to be more explicit about it.
Nigel: OK
I think it's a note alongside the other text on styling.
I have started work on a pull request for styling, for issue
29, so I'll include this in that.
SUMMARY: Permit inline styling
Consider timing syntax constraints w3c/dapt#59
<Github> [17]https://github.com/w3c/dapt/issues/59 : Consider
timing syntax constraints
[17] https://github.com/w3c/dapt/issues/59
Nigel: In particular this one is about prohibiting use of the
dur attribute
At the moment we say begin and end attributes must be
present.
One issue is about adaptation, where @btsimonh suggested
omitting end attributes within spans,
but allowing begin attributes as a mechanism for specifying
word timings.
So two questions: 1, the attributes we permit, and 2. the
syntax of time expressions themselves.
I think we want to say nothing about time expressions?
I think the only time constraint is that the timebase must be
media.
Cyril: This is the type of question where we need feedback from
implementers.
Do they need all the options?
I don't have a strong opinion either way.
The choice of begin and end was for simplicity.
Pierre: Even more obscure, if timeContainer is seq or par. That
one is pretty safe to forbid I think,
at least to specify that it will always be par.
(by prohibiting it from being specified)
Nigel: However there's a use case for seq here!
Cyril: There's a difference between timing at event level,
where only one is active at any time.
Nigel: I thought we need to handle multiple speakers at the
same time?
Cyril: Oh yes, forget that.
Nigel: My AD use case is to slightly simplify the expression of
"fade, mix AD in, fade back" as three
always sequential things, where the begin of each is the end
of the previous.
However I've never done it that way, I've always explicitly
set the times using par.
I'm happy to stick with par unless we hear otherwise.
Cyril: Let's do that. If we want to map to IMSC, seq is not
allowed, right?
Pierre: No, it is allowed in IMSC.
I'll check
Yes, pretty sure there's no restriction.
Nigel: The advantage of prohibiting it is simpler
implementation,
the con is it might prevent some authoring cases.
Pierre: I think they're always mappable one to the other, so
simplifying parsing marginally might be good.
I suspect that the first writers of IMSC would have forbidden
seq had they been aware of timeContainer.
Nigel: I propose to mark timeContainer as prohibited,
Pierre: I would not constrain dur
Nigel: Yes, I'm a bit concerned about that.
Pierre: It's not worth the risk given the complexity of
implementation.
Nigel: So I propose we permit dur.
And then for the time expression syntax, I propose we leave
it open to anything in TTML, but
add an editorial note requesting specific feedback on this
point, to highlight the question during wide review.
Cyril: IMSC has no restrictions on time expressions?
Pierre: No, I think it had a recommendation of using begin and
end but that is not present now.
The good news is there are multiple implementations of
temporal syntax computation/resolution
so the risk there is not great.
One way to limit the risk is to provide really good examples
and templates.
Cyril: Do we really need wallclock time?
Pierre: That's a different question - IMSC only does media
time.
Cyril: No, my question was ambiguous. The definition of time
expression includes wallclock time.
Pierre: In IMSC there are no restrictions. All the options are
permitted. Oh, but not #time-wall-clock, that's prohibited.
Cyril: I want to prohibit it here too.
Nigel: I have no use case for it, happy to prohibit it.
Cyril: What about timebase? Media only?
Nigel: Yes, I would say so.
I think I proposed it somewhere, very happy to confirm.
Cyril: There's one issue here, which is #45, about
synchronisation.
Nigel: Yes, that's where I proposed it.
Cyril: I think we did agree, but did not capture it clearly.
It's not implemented in the spec.
Nigel: OK we'd better do that!
Cyril: Actually in the feature list constraints it does do
this, but it's not in the text.
Nigel: We still need to review all those dispositions. Formally
it's there, agreed.
SUMMARY: timebase must be media, no wallclock, no
timeContainer, permit dur, don't be dogmatic about presence of
begin and end everywhere
Cyril: Do we need begin somewhere though?
Nigel: In the extreme case of a short clip it may be only
occupied with one utterance for the entire duration,
so it would not add anything to specify begin and end.
Rechartering status update
Nigel: At end of TPAC Atsushi was preparing the team report for
the FO Council experiment.
Since then there has been a bit of chatter on the charter
draft pull request from Apple, but I don't
think it's gone anywhere particularly helpful. The PR was
rebased.
Atsushi, how are you getting on, do you need anything from
us?
Atsushi: It's finished, and a call for participation for the FO
Council was opened from this Monday
for 2.5 weeks. FO Council may start in mid October.
Before that, the team report will be shared with the TTWG and
the formal objector, to get any comments.
That's the current status.
Nigel: That call for participation was this Monday just gone?
Atsushi: Yes
Nigel: Any questions from anyone on this?
Group: No questions.
Rather than using ttm:role for script type, define new attribute
w3c/dapt#54
<Github> [18]https://github.com/w3c/dapt/issues/54 : Rather
than using ttm:role for script type, define new attribute
[18] https://github.com/w3c/dapt/issues/54
Github: [19]https://github.com/w3c/dapt/issues/54
[19] https://github.com/w3c/dapt/issues/54
Nigel: Suggestion at the moment is to define a new attribute in
daptm: namespace for the script type.
Other alternatives are:
1. Add values to ttm:role via registry
2. Use some other existing metadata such as something defined
by EBU in ebuttm: namespace
It occurred to me that the path of least resistance is to
define a new attribute.
Then there's the question of future flexibility, where I
suggested we define the value space in a registry.
Do we have semantic or syntactic constraints on the document
based on script type?
Cyril: Yes, for example Character is mandatory when dubbing.
So depending on the script type value you may require this or
that.
The more I think of it the more I prefer a specific attribute
rather than making implementers worry about ttm:role and its
other possible values.
This way we isolate/limit the work to be done.
My take on registry is only introduce it if we need to in the
future.
It would only be editorial?
Nigel: It's possible to have registry tables embedded in Recs
Cyril: I would prefer to avoid that for now.
Nigel: That's fine for me, let's do that.
SUMMARY: Define new script type attribute and don't make it a
registry
Meeting close
<atsushi> [20]https://www.w3.org/2002/09/wbs/35125/
tpac2022-Hybrid/
[20] https://www.w3.org/2002/09/wbs/35125/tpac2022-Hybrid/
Atsushi: For AOB, please feed back on the WBS survey about
hybrid TPAC, link above.
Cyril: I did actually submit it, we received it on the last
day, the Friday
Nigel: I didn't notice it, will look. Thanks.
Nigel: We're over time for today, let's adjourn, thanks all.
Next meeting is in two weeks.
If we need more frequent meetings while we are doing a lot of
editorial work we can increase the frequency.
Cyril: That might work in November - October is very busy with
other events.
Nigel: Let's bear that in mind as a possibility.
Pierre: If it gets to the point where there are a few
significant issues, we can plan an in-person meeting
if that would help.
I mention it now because it takes more planning.
It's mostly DAPT folks - the rest we can deal with remotely.
Nigel: Thanks, that's a good place to end. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[21]scribe.perl version 192 (Tue Jun 28 16:55:30 2022 UTC).
[21] https://w3c.github.io/scribe2/scribedoc.html
Received on Friday, 30 September 2022 16:19:10 UTC