Timed Text Working Group Teleconference

22 June 2023


Atsushi, Chris, Chris_Needham, Cyril, Nigel, Pierre
cpn, nigel

Meeting minutes

This meeting

Nigel: Today we have:
… IMSC-HRM transition to CR
… DAPT including issues and pull requests for discussion
… TPAC 2023 planning
… Any other business, or points to cover within the above?

no other business

IMSC-HRM transition to CR

Nigel: We have transition to CR, thank you Atsushi and Pierre


Atsushi: It was published today
… It was announce to the AC and Chairs, not sure if it's on the blog yet

Nigel: It is in the latest news, yes

IMSC-HRM CR Publication News post

Nigel: Next steps, to exit CR we have to have tests
… How we do that will be an interesting conversation
… Do we have a repo already?

IMSC HRM Tests repository

Pierre: I have an action item to do that, we should issue a call for content

Nigel: I don't mind splitting the tasks

Pierre: I'll get started on creating synthetic tests, and if you have the chance to start on the call for content, we can circle back

Nigel: That works
… I'm not working during most of August, lots to do before then

Pierre: Maybe start with the call for content? I could start a document and send to you
… Thanks everyone for getting the CR out

Nigel: I second that
… Anything else on this?



Nigel: We have been merging some PRs, and have begun the horizontal review tasks
… There's some complexity with HR, particularly accessibility, where they have 2 checklists, neither is markdown

FAST checklist

Nigel: The FAST checklist has a lot of rows and notes in the middle column, and subsections. Does anyone know of a good way to get this into markdown that we can easily edit?


Nigel: We've created pages in the DAPT wiki to work on it
… So we post the checklists there, rather than in GitHub issues, and refer to them in the HR requests
… Accessibility, Privacy and Security, and TAG
… Cyril and I will work on completing those
… I also created a wide review section in the wiki. I have a task to contact other organisation, and do other outreach
… For example, I presented DAPT to the EBU timed text group in May, and then in MEIG, also last week to the EBU access services experts plenary (hosted by RTS in Belgrade)

Slides for EBU Access Services Experts meeting in Belgrade, 2023-06-16

Nigel: I have been talking about it, but not writing, so need to do that next

Atsushi: On the markdown, I think I copied the first column as text

Nigel: Has any change been made since you did that?

Similar review markdown for webxr

Atsushi: I think I can do the same for DAPT

Nigel: Yes please

Nigel: Setting up auto-publishing is done and works nicely [removes bullet from the agenda]

Nigel: Let's look at issues and PRs

Cyril: I saw your comments, I need time to address them, I don't see anything major
… Have we made a decision about original language attribute?

Consider identifying the original language on top of the current language w3c/dapt#148

Github: w3c/dapt#148

Cyril: In my work to round trip between TTAL and DAPT I found one piece of information missing, useful in pre-recorded script is useful to know the original language even if you don't have the script any more

Nigel: That's having the original language text?

Cyril: Yes. But wondering what's wrong with carrying the original language text all the way through. Don't think we're concerned about the size of the document

Nigel: Don't know enough about the use cases to know if it's useful. If there's a question over the accuracy of translation and there's a pivot language involved, you may want to know which was used for translation, the pivot or the original
… How do we discover if this is actually needed?

Cyril: I need to survey our Netflix users
… The lang source attribute has two values: original and translation. We could add a third, "pivot"?
… I'll consult internally and then we can decide whether to merge this or not

Clarify how to use SSML with DAPT w3c/dapt#121

Github: w3c/dapt#121

Nigel: At the moment, in TTML2 we have two audio styling attributes that direct the use of text to speech
… They are derived from SSML semantics
… But the vocabulary and structure is different
… An obvious direction we should plan for is to allow a richer feature set from SSML so people can direct the text to speech more directly
… We could define all the syntax in TTML and a mapping to SSML, or inject SSML into the TTML document
… But then, what happens to the two bits of vocabulary already in TTML2
… If injecting SSML, do it with an element structure or an attribute?
… The new thing, is thinking about the voice characteristics. Maybe a good idea is to associate the voice with the agent, then your mapping to SSML would pull in that metadata and use it
… We always had a rule that metadata doesn't drive presentation, but we'd be going against that

Cyril: The one other detail, if we were to embed SSML in DAPT, the TTML behaviour is to prune elements not in the TTML namespace, for validation
… I wonder if the entire element would be ignored for the purpose of rendering, or would its internal text content be used. That would make a big difference

Pierre: So if you wrap text in an unknown element, would it still be used?

Cyril: Yes, it's something you can do in HTML
… Nigel, I think your point about using agent to indicate voice characteristics, I like the idea
… Not a problem in the metadata vocabulary. I think it's a good way to do it

Nigel: OK, it sets us down an interesting path, of how to map SSML semantics into TTML. Need to plan ahead, do a thought experiment of the best mapping into TTML if we need them in the future

Cyril: Your comment in the PR 157 about proprietary metadata is relevant


Cyril: The metadata we're thinking about is what speech generation engine you want to use, etc. Does SSML cover all that?

Nigel: [Reviewing the details] They go quite far, I think
… The synthesis processor specifically, I'm not sure you can specify
… I think the idea is you can pass the SSML to any processor, but doesn't contain a pointer to the synthesis processor itself
… I would need to check, but I think that's how it is
… Yes, the synthesis processor external

Nigel: For TTML validation it would prune, also imscJS rendering

Cyril: Is there a normative statement for that?

Pierre: There's a note, if you try to feed a TTML2 document with ruby to a TTML1 processor, it may prune the entire element
… I wouldn't count on the presentation processsor keeping the content of the element
… Why not use a span with the content if you want to keep it?

Cyril: Need to define a transformation between TTML and SSML could be in XSLT

Nigel: The [construct intermediate document] process prunes elements if they are not "presentation related"
… You could assert that some SSML element must be included in some presentational element in DAPT
… A simple reading, you wouldn't expect that

comment in imscJS

Cyril: If your implementation is both a TTML and SSML processor, you may keep it

Pierre: There's a comment in imscJS about ignoring elements not in TTML namespace if they're not inside a metadata element

Cyril: In DAPT we could say something about how to mix SSML and TTML, that would be defining behaviour in fuzzy areas in TTML
… The benefit of basing DAPT on TTML is you can embed it in generic TTML processors

Pierre: If you want the benefit of TTML, stay with TTML. But if you need something other than TTML, imscJS or other processors would eventually recognise it
… If not needed, don't do it, but if it's needed it's needed

Cyril: Mapping to a different stucture seems like unnecessary work, and would have to be maintained

Pierre: What's different between them?

+1 to avoiding unnecessary work, which it seems to be

Nigel: More granular directives for text to speech

Pierre: Do the opposite, embed TTML in SSML?

Cyril: But the DAPT document is the whole thing
… The example I put in issue 121, is because Netflix uses some SSML engine for voice synthesis
… At the moment we have a proprietary TTAL spec, generate SSML, then send to an API
… Speech rate is covered, but there's a phoneme span that gives pronunciation

Pierre: In the issue there is a link to a new spec for spoken presentation in HTML. It uses attributes instead of elements

Nigel: It describes both strategies, seems they're not sure which is the best to use

Cyril: So we could say use the same attribute
… That mapping works for us too

Pierre: Presumably. HTML has the same issues as us

Nigel: These things can be on spans

Pierre: And semantically they should be, they convey additional semantics on text

Cyril: We could adopt their strategy but not their spec

Nigel: We could define a dapts: namespace that exactly map to the SSML voice element content

Cyril: Which group is working on the spoken presentation in HTML?
… It's a TF in APA WG

Nigel: The attribute approach seems nice, we're gravitating towards that

Cyril: I prefer the multi-attrbute rather than single attribute approach

SUMMARY: Gravitating towards multi-attribute approach maybe in a ssml-specific DAPT namespace

TPAC 2023 planning

TPAC schedule

Nigel: The TPAC schedule is published, we meet on Tuesday 12 September
… We need to cover joint meetings. APA WG has asked for a joint meeting, Thursday afternoon
… I said that may not be a good time for those going to IBC, but it may be possible
… Their agenda is markup for chapter titles, inter-linear publications, specialised handling of media, Music XML, multiple tracks of sign language
… Not sure we'll have views on any of them

Chris: I think this is a multi-way group meeting. I've also been talking with them.
… They've come to MEIG as well.
… To talk about the Media Accessibility User Requirements - they want to restart work on it.
… I haven't discussed any detail of what that might involve with them.
… I'm planning to in the next MEIG meeting.
… Later there will be a TPAC meeting which I think the request is TTWG + MEIG + Media WG + APA
… Basically everybody media!

Nigel: So I suggest saying yes, but propose talking about SSML in HTML too

Chris: Sounds good to me since that document is their work item.

Nigel: I don't know if there's a better timeslot than the Thursday or Friday?

Chris: I think I suggested that one. Maybe Tuesday morning?

Nigel: That's when we're meeting.

Chris: I avoided Tuesday afternoon for the AC.

Nigel: Let's say yes and worry about the timing later.

Chris: The other thing I wanted to talk about is a meeting with Media WG and MEIG
… to look at the Text Track API and potentially other things if you have them
… For that, we could probably cover it in the MEIG Monday time rather than figuring out a new timeslot.

Nigel: Works for me. Only slight concern is prep time for TTWG but that's a second order problem.
… In the past we were able to meet as TTWG before any joint meetings.

Chris: Shall I pencil that in for the Monday morning, and then figure out the detail of what we want to cover?

Nigel: Sounds good to me
… Agenda-wise, we don't have anyone active now on WebVTT. It's been stuck without republication for years
… TPAC could be time to discuss that
… That could be good to raise, just to seek direction, explain current situation and see if anyone wants to step up

Pierre: We've had this discussion over the years. Absent anything else, I'd expect WebVTT to move to WHATWG
… The drawback is it creates an additional forum for people interested in timed text. Not sure that's a good outcome for the community


Nigel: It's a possible agenda item

Pierre: It's a thing for W3C strategy, what does it want to do with WebVTT?

Meeting close

Nigel: We're out of time for today, thank you Chris for scribing, and thanks everyone. [adjourns meeting]

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).