- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 22 Jun 2023 16:34:19 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <203BCC6B-23AE-41C2-8CAB-4C13E355C059@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2023/06/22-tt-minutes.html
In text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
22 June 2023
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2023/06/08-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/254
[4] https://www.w3.org/2023/06/22-tt-irc
Attendees
Present
Atsushi, Chris, Chris_Needham, Cyril, Nigel, Pierre
Regrets
Andreas
Chair
Nigel
Scribe
cpn, nigel
Contents
1. [5]This meeting
2. [6]IMSC-HRM transition to CR
3. [7]DAPT
1. [8]Consider identifying the original language on top
of the current language w3c/dapt#148
2. [9]Clarify how to use SSML with DAPT w3c/dapt#121
4. [10]TPAC 2023 planning
5. [11]Meeting close
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
[12]IMSC-HRM CRS
[12] https://www.w3.org/TR/2023/CR-imsc-hrm-20230622/
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
[13]IMSC-HRM CR Publication News post
[13] https://www.w3.org/news/2023/w3c-invites-implementations-of-imsc-hypothetical-render-model/
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?
[14]IMSC HRM Tests repository
[14] https://github.com/w3c/imsc-hrm-tests/
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
[15]FAST checklist
[15] https://w3c.github.io/fast/checklist.html
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?
[16]DAPT Wiki
[16] https://github.com/w3c/dapt/wiki
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)
[17]Slides for EBU Access Services Experts meeting in Belgrade,
2023-06-16
[17] https://bbc.github.io/accessibility-presentations/nigel_megitt_ebu_access_services_2023/index.html
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?
[18]Similar review markdown for webxr
[18] https://github.com/immersive-web/webxr-ar-module/issues/84
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 [19]w3c/dapt#148
[19] https://github.com/w3c/dapt/issues/148
Github: [20]w3c/dapt#148
[20] https://github.com/w3c/dapt/issues/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 [21]w3c/dapt#121
[21] https://github.com/w3c/dapt/issues/121
Github: [22]w3c/dapt#121
[22] https://github.com/w3c/dapt/issues/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
[23]https://github.com/w3c/dapt/pull/157#discussion_r1234279959
[23] https://github.com/w3c/dapt/pull/157#discussion_r1234279959
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
[24]comment in imscJS
[24] https://github.com/sandflow/imscJS/blob/7716bccfa716be4df0bcd3a8ac0809d1ef8e2023/src/main/js/doc.js#LL555C1-L556C1
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
[25]TPAC schedule
[25] https://www.w3.org/2023/09/TPAC/schedule.html
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]
Minutes manually created (not a transcript), formatted by
[26]scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).
[26] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 22 June 2023 16:34:40 UTC