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
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
DAPT Issues and Pull Requests labelled as 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 w3c/dapt#173
github: w3c/
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. w3c/dapt#177
github: w3c/
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
Using the ITU BT.2100 PQ EOTF with the PNG Format
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: w3c/
… There's no way in the Process to obsolete a Note
github: w3c/
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]