- From: Nigel Megitt <nigel.megitt@bbc.co.uk>
- Date: Thu, 3 Aug 2023 16:25:42 +0000
- To: TTWG <public-tt@w3.org>
- Message-ID: <22C18C5C-0EC0-425E-B9A6-2E4E97C655E4@bbc.co.uk>
Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2023/08/03-tt-minutes.html
Our next call will be on 2023-08-31, in 4 weeks.
Those minutes in text format:
[1]W3C
[1] https://www.w3.org/
Timed Text Working Group Teleconference
03 August 2023
[2]Previous meeting. [3]Agenda. [4]IRC log.
[2] https://www.w3.org/2023/07/20-tt-minutes.html
[3] https://github.com/w3c/ttwg/issues/257
[4] https://www.w3.org/2023/08/03-tt-irc
Attendees
Present
Andreas, Atsushi, Chris, Gary, Matt, Nigel, Pierre
Regrets
-
Chair
Nigel
Scribe
cpn, nigel
Contents
1. [5]This meeting
2. [6]IMSC-HRM
3. [7]DAPT
1. [8]Issues and PRs for discussion
2. [9]Use of the value "Original" for Text Language
Source when it refers to non-dialogue sound
w3c/dapt#173
3. [10]Add examples of bidi in desc and bidi in p.
w3c/dapt#177
4. [11]TPAC 2023 Planning
5. [12]Using the ITU BT.2100 PQ EOTF with the PNG Format
6. [13]Meeting close
Meeting minutes
This meeting
Nigel: Agenda for today:
… * IMSC-HRM
… DAPT
Nigel: TPAC 2023 planning
Nigel: Any other business, or points to make sure we cover?
group: none
IMSC-HRM
Nigel: I think the main point here is the call for
implementations
… Pierre, you drafted some text didn't you?
Pierre: Yes
… I've been contacting people privately.
Nigel: I think that's fine, we don't need to do more than that.
… I have seen one response from Andreas offering to process
some content.
… Anything more to be said for now?
Pierre: No, it's summer so hard to get attention, but I'm
optimistic we will get at least
… 2 content implementations in the fall
Nigel: Thanks, action remains with all to prompt any contacts
to get in touch if they can
… process content from implementations through the HRM
validator.
Pierre: We should try to set some kind of timescale to be done
before, say, the New Year.
… If you know anyone with a collection of IMSC, EBU-TT-D,
SMPTE-TT files, please alert them
… and ask them if they could run a proportion of their content
through the HRM, that'd be great, thanks.
DAPT
Nigel: Updates from me:
Nigel: For wide review and horizontal reviews, we've sent all
the horizonal review emails out. We want to get feedback from
companies who do translation, but don't have a good list
… If anyone wants to get in touch with their favourite provider
to ask feedback, that would be awesome
… From a formal perspective, we've done what was needed for
charter
… That's the non-horizontal review stuff
Andreas: If we know someone we could contact, should we do it
through you or via liaison or just point them to the draft and
ask feedback?
Nigel: I don't mind, but I'll be away for August, so don't want
to be a blocker
… If any of those orgs will be at IBC, I'd be happy to meet
them there
Andreas: OK
Matt: Have you contacted MESA? I was looking for a contact
there
Nigel: I don't think I have, but would love to
Matt: Let me see if I can find someone
Nigel: Thank you
Nigel: On horizontal reviews, we've started Accessibility,
Privacy, and Security reviews
… That leaves TAG and i18n
… Cyril took the action to do those
… and to write an explainer in the DAPT wiki
[14]DAPT Explainer
[14] https://github.com/w3c/dapt/wiki/DAPT-Explained
Nigel: Comments and feedback would be welcome. The explainer is
a prerequisite for TAG review, and i18n also appreciate it
… We've made some spec changes to improve i18n. Their checklist
generated an issue to do with how we represent bidirectional
text in attributes
… Also in the TTML metadata elements, which only permit PCDATA
and not markup to signal bidirectional text
… We made some editorial changes to the DAPT spec to help
explain how that situation can be dealt with
… There's a remaining issue, #177, about adding an example
… Cyril is on the hook to request the TAG and i18n reviews
… The other thing we haven't done yet: we merged the draft
boilerplate text for registries, but haven't created the
registries that DAPT needs
… Not sure we can go to CR without it
… I haven't had time to come up with a plan, add to DAPT itself
or put into a separate document
Chris: Question: what is expected to go in the Registries, and
what would be the lifecycle for updating
… them compared to DAPT itself.
… If you put the Registry in the spec then you have to produce
a new version of the spec, either a
… CRS or an updated Rec, for adding a new registry entry. If
you do it separately then the updates
… can be managed in a different way.
Nigel: As I understand it from the current Process, sections of
specs that are registries can be updated without going through
a process to update the CR or Rec
… So can be done either way and it should be OK
… I'd expect the registry entries to be changed more often than
DAPT would be changed
… The nice thing about putting the registry as a table in the
spec, is there's just one document to look at rather than
dereference the spec to another document
… That suggests what I want the answer to be
… It would be good to confirm what the Process requires for
changing a registry entry in a spec
Issues and PRs for discussion
[15]DAPT Issues and Pull Requests labelled as Agenda
[15] https://github.com/w3c/dapt/labels/agenda
Nigel: We had a PR that didn't build correctly, we rely on a
GitHub Action, v2 checkout, but it logs a warning about a
deprecated version of Node
… Atsushi, will you check that's OK before we merge the PR?
Atsushi: I should check with the spec-prod action
Nigel: That's fine, it's not urgent
Use of the value "Original" for Text Language Source when it refers
to non-dialogue sound [16]w3c/dapt#173
[16] https://github.com/w3c/dapt/issues/173
github: [17]w3c/dapt#173
[17] https://github.com/w3c/dapt/issues/173
Nigel: Andreas made the point that there's a problem with
transcribing and translating things not spoken and not written.
For example, a scene where there's something visual that you
want to decscribe
… or a sound, not someone speaking, such as a door slam, how do
you label the transcript of that in terms of its language
source?
… I attempted to change the text in PR #179. Thanks Andreas for
your helpful review
… There's this category of stuff, not non-verbal. Some
languages don't have a written down form, e.g., sign languages
… They would count in this, if you transcribe someone signing
… But I don't know a generic term for that kind of thing,
something without an inherent written language
Pierre: Sign language has a language tag
Nigel: But if you're going to transcribe it into timed text,
you'd do it in a language of your choice
Pierre: So what's the issue then?
Nigel: It's partly terminology, how we talk about this kind of
transcript text in the DAPT spec
Pierre: There's dialog, music and effects, background sounds
that could be transcribed, visual elements such as road signs
… A scene where somebody is signing might be good to transcribe
… Are you trying to label what they are or their source?
Nigel: Trying to come up with terminology to talk about things
we're going to transcribe
… If a programme is in Dutch, most of the stuff you're
transcribing is in Dutch. If you're also transcribing a sound,
you'd do that in Dutch as well
… If audio describinng, would be in Dutch. If translating for
another language, you'd translate all the transcript to the
other language
… We have a text language source, can be original or
translation at the moment
… Andreas has an interesting proposal
Matt: If you've written sign language down you've translated.
If you written BSL down in English, you've translated to
English
… There isn't an alphabet based written form, there are drawn
descriptions of the signs
+1
Matt: For fear of upsetting people, we should be careful about
terminology
Gary: One of Pierre's points was about signs and things not
auditory descriptions. Would it be worth having a way to
differentiate that as well?
… Could non-dialog be better than non-verbal? It gets
complicated, if sign language is a translation, it's
technically also dialog
Andreas: : After looking at your proposal, which makes the
problem clear, there possibly is no need to catch the text
language source
… If there is no inherint language for content e.g. for non
verbal sound we may not need the property Text Language Source
because it does not not apply.
Nigel: I think it's mandatory, so I think we'd need to make it
non-mandatory or add other values to the enumeration
Gary: If the original description is in Dutch and you're
translating, unless you're writing a new description in the
target language, the language would be Dutch
Nigel: That's what I thought
… I think there's another iteration to do to capture the
options more precisely
… We need to track when something has been translated and when
it hasn't
… I've just added the signing as another part of the problem,
but could handle it differently. They're interpreting it into
the original language for the transcript, but they could have
chosen a different language
… Perhaps there's a distinction to make between someone
speaking in an original language vs an interpretation in the
first language the transcript was written in
SUMMARY: May be worth another iteration thinking about this: in
particular, distinguishing between original-in-source and
original-interpretation-for-transcript.
Add examples of bidi in desc and bidi in p. [18]w3c/dapt#177
[18] https://github.com/w3c/dapt/issues/177
github: [19]w3c/dapt#177
[19] https://github.com/w3c/dapt/issues/177
Nigel: In the i18n review we realised you can't put
bidirectional markup in TTML metadata elements or attributes,
but you can put them into content elements
… The suggestion was, as well as writing notes on how to
achieve this, use paired Unicode control characters as a
fallback
… Should we add examples of those into DAPT, to show exactly
how this is done, nor ot?
… Let's do a poll, +1, 0, or -1 where positive = yes add
examples, negative means do not, zero means "don't care"
<MattS> +1
<atsushi> +1
<MattS> (I always think it's good to illustrate stuff)
-1
0
Gary: it sounds like this is a pattern we don't want to
encourage
… If we don't want people to use it unless they have to, I'd
lean towards not documenting it, as documenting it would lead
more people to doing it
Nigel: A method for bidirectional text is required, so the
question is whether to give an example
Matt: Examples are always good. It's hard to know what is meant
when there's just text. And we find many suppliers don't get
XML, so having something unambigious is good
… I've found suppliers asking for examples
Andreas: This is a general issue and if we do examples than may
be should to in a separate note.
Matt: I'd second that
<pal> +1
<gkatsev> +1
SUMMARY: Net vote in TTWG call 2023-08-03 is in favour of
adding examples.
TPAC 2023 Planning
Nigel: I haven't listed the meeting and joint meetings, and
haven't done a lot on the agendas
Chris: I need to have a look too. From the MEIG perspective we
have a 45 minute slot on the Monday
… morning.
Nigel: I think we need to use that to talk about IMSC-HRM and
DAPT.
Nigel: Won't have time until end of August to summarise and put
in one place, so if someone wants to volunteer? I welcome
suggestions for other topics
Chris: I think there was a suggestion (from Gary?) to talk
about the Text Track API
Gary: Yes, we did talk about it, but I probably won't attend
Chris: Happy to include it if someone wants to present or drive
that discussion
Using the ITU BT.2100 PQ EOTF with the PNG Format
[20]Using the ITU BT.2100 PQ EOTF with the PNG Format
[20] https://www.w3.org/TR/png-hdr-pq/
Pierre: This WG Note was approved in 2017. At time there was no
way to carry PQ encoded images in PNG
… The Note reflected industry practice, which was to write PQ
or HLG pixels and signal use of non-SRGB pixels in PNG
… There's a PNG 3rd Edition coming soon, with native signalling
for HDR pixels, PQ and HLG
… An issue was filed by Chris Lilley
Pierre: I think this WG needs to review the PR, which
deprecates the Note, essentially: [21]w3c/png-hdr-pq#13
… There's no way in the Process to obsolete a Note
[21] https://github.com/w3c/png-hdr-pq/pull/13
[22]w3c/png-hdr-pq#13
[22] https://github.com/w3c/png-hdr-pq/pull/13
github: [23]w3c/png-hdr-pq#13
[23] https://github.com/w3c/png-hdr-pq/pull/13
Pierre: Give a month for review?
Nigel: Thank you for calling our attention to this
… I have no objection to deprecating if it's no longer needed
Pierre: There are files out there that use it, but makes sense
to deprecate for new files
Nigel: Presumably there's versioning information in the PNG,
and people using older versions still need to reference this
Note?
Pierre: Systems use the magic string. For new systems, the
recommendation is to use the new signalling capabilities in PNG
which new implementations can look for
… We can't remove the document because of existing usage
Nigel: Makes sense
SUMMARY: TTWG alerted to the need to review this pull request
Meeting close
Nigel: Next meeting is not in 2 weeks time, instead it's August
31
… Have a good 4 weeks!
Atsushi: Don't forget to register for TPAC if you're attending,
and book hotel rooms etc.
everyone expresses warm wishes to each other over the short
summer break
Nigel: Let's adjourn for today. Thanks again Chris for
scribing. [adjourns meeting]
Minutes manually created (not a transcript), formatted by
[24]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).
[24] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 3 August 2023 16:26:21 UTC