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
DAPT Issues marked for the agenda
Should we allow inheritance of xml:lang or require it to be set explicitly? w3c/dapt#62
<Github> https://
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> https://
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> https://
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> https://
Github: https://
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> https://
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]