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?
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?
(nothing)
DAPT
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
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/
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/
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
https://
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
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
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
+1
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]