{Minutes} TTWG Teleconference 2023-07-20

Thanks all for attending today’s TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2023/07/20-tt-minutes.html


In text format:

   [1]W3C

      [1] https://www.w3.org/


                Timed Text Working Group Teleconference

20 July 2023

   [2]Previous meeting. [3]Agenda. [4]IRC log.

      [2] https://www.w3.org/2023/07/06-tt-minutes.html

      [3] https://github.com/w3c/ttwg/issues/256

      [4] https://www.w3.org/2023/07/20-tt-irc


Attendees

   Present
          Atsushi, Chris, Matt_Simpson, Nigel, Pierre

   Regrets
          Andreas

   Chair
          Nigel

   Scribe
          cpn, nigel

Contents

    1. [5]This meeting
    2. [6]IMSC-HRM
         1. [7]IMSC-HRM Tests
    3. [8]DAPT
         1. [9]Support within workflowType for generic script
            origination w3c/dapt#169
         2. [10]Registries
    4. [11]Meeting Close

Meeting minutes

  This meeting

   Nigel: On today's agenda we have:
   … * IMSC-HRM
   … * DAPT
   … * TPAC 2023 planning
   … Is there any other business, or points to make sure we cover?

   group: no other business

  IMSC-HRM

    IMSC-HRM Tests

   Nigel: Thank you Pierre for putting together the pull request
   to add IMSC-HRM tests

   github: [12]w3c/imsc-hrm-tests#1

     [12] https://github.com/w3c/imsc-hrm-tests/pull/1


   Nigel: notes that w3c/imsc-hrm-tests needs to be added to
   github bot's list

   Nigel: I sent an email Friday last week, asking to be allowed
   to merge before the normal 2 weeks
   … Andreas approved. Pragmatically, I'm happy to merge this, we
   can point implementers to the tests
   … Are there any objections to doing that?
   … No objections, Pierre, feel free to merge

   Pierre: Thank you

   Nigel: The next steps are the call for implementations. This is
   really a call for everyone who can to share that we're looking
   for evidence of implementation
   … That could be a large body of content that passes the
   validator or meets the requirements of IMSC HRM

   Pierre: [13]https://docs.google.com/document/d/

   1J0kPIKXyS7RT_nTA4bYueC0e1AoatyLeHkWtr_5dZzc

     [13] https://docs.google.com/document/d/1J0kPIKXyS7RT_nTA4bYueC0e1AoatyLeHkWtr_5dZzc


   Nigel: When we published CR we also published a blog post that
   requests implementations. This is a more refined version of
   that request

   Pierre: It's intended to be really targeted
   … It's a substantial amount of effort to pull content from
   libraries and run the HRM. Alternately, create an
   implementation of the HRM and synthetic content as an
   independent test vector
   … To maximise the chances of people hearing about it, we should
   send directly to people or groups who may be interested, as a
   personal email
   … We could do it formally, or add names to a spreadsheet to
   avoid sending to the same person twice

   Nigel: With DAPT, we used the wiki in the repo to have an
   outreach log
   … I don't think there's sensitivity about publishing who we've
   asked. But if there is, we could do it in the member-only wiki

   Pierre: Might not be sensitive if it's by company

   [14]News post requesting implementations of IMSC-HRM

     [14] https://www.w3.org/news/2023/w3c-invites-implementations-of-imsc-hypothetical-render-model/


   [15]IMSC-HRM repo wiki

     [15] https://github.com/w3c/imsc-hrm/wiki


   Pierre: Maybe we can use the the implementation report wiki, to
   keep it all in one place

   Nigel: That's fine too

   Pierre: We should add a link to the wiki from GitHub, by the
   way
   … [16]https://www.w3.org/wiki/TimedText/

   IMSC-HRM-1ED-Implementation-Report

     [16] https://www.w3.org/wiki/TimedText/IMSC-HRM-1ED-Implementation-Report


   Nigel: An action to take is tabulate the different tests into
   the implementation report, to show which implementations pass
   which tests

   Pierre: I can do that

   Nigel: Looking at the call for content text, the note saying
   that image profile support will be removed. There's a chicken
   and egg problem, if we don't make tests we can't include the
   feature in the end

   Pierre: Either the community cares and will contact us, but if
   not we shouldn't feel bad about removing the feature. I know
   it's in use, we get bug reports on IMSC.js

   Nigel: I'll add words on image profile, as we're looking for
   help

   Pierre: The date is there to set expectation for when to
   respond

   Nigel: Let's allow more time, say, October

   Pierre: Do you have people in mind?

   Nigel: Yes, two as implementers. For bodies of content, I
   should be able to do some myself, but unsure who else to ask
   … Matt, would be handy also if you also want to?

   Pierre: Content that's actually in production

   Matt: We may have some IMSC material. I don't think we have
   anything suitable off the shelf
   … We can try generating from some of our tools

   Nigel: We're looking for real audience facing content that
   meets HRM requirements

   Matt: I can run through some of our content

   Pierre: That would be awesome

   Nigel: Shall we follow up offline on who to contact?

   Pierre: OK

   Nigel: Is there anything else to do on IMSC HRM?
   … Hearing no. Thank you for creating all those tests. Pierre
   and I talked last week, and the way the tests are organised
   might hint at improving the specification structure itself
   … I can raise an issue on that. It's about how we define the
   available time to render an ISD, as the lesser of IPD and time
   from prevous ISD
   … It would simplify one of the complicated bullet points in the
   spec

  DAPT

   Nigel: I sent lots of requests for wide review. We don't have a
   contact for ITIC, Pierre you might be able to help?

   Pierre: I've pinged them, they're usually responsive, so I'll
   follow up with them
   … I suspect this might not be on their radar

   Nigel: The other thing we need to do is horizontal review. I
   completed and reviewed with Cyril the accessibility self
   review, also the security and privacy self review
   … I raised the review request with the APA WG

   [17]DAPT Wide Review outreach log wiki page

     [17] https://github.com/w3c/dapt/wiki/Wide-Review-outreach-log


   Nigel: I have been logging everything I've done in the wiki
   … I can't do the next action, the security and privacy reviews
   without adding sections on those to the spec
   … I raised a PR to do that, awaiting review. If anyone can
   review, please do

   [18]Pull request to Add Privacy and Security Section
   w3c/dapt#168

     [18] https://github.com/w3c/dapt/pull/168


   Nigel: There's an action on Cyril to request the TAG and i18n
   reviews
   … Some issues to discuss. One of the internationalisation
   points is about holding information only in attributes. You
   can't sensibly have markup in attributes so if you need to mix
   LTR and RTL in attributes, it's tricky
   … It's a problem in DAPT as we've specified that some
   human-readable text, such as remarks on translations, are put
   into metadata attributes like ttm:desc
   … TTML has long had this feature already, allowing some kinds
   of metadata just to be in attributes
   … ttm:desc is element, not an attribute. The content specified
   for ttm:desc is PCDATA only, not mixed content that can contain
   spans with markup
   … So if you want to markup language or direction on different
   parts of a ttm:desc element, you can't
   … It also applies to ttm:name, ttm:item, ttm:copyright

   <atsushi> [19]https://www.w3.org/TR/

   international-specs/#bidi_inline_change

     [19] https://www.w3.org/TR/international-specs/#bidi_inline_change


   Atsushi: Does it relate to the requirement in this URL?

   Nigel: Yes

   Atsushi: If I understand correctly, markup is preferred

   Nigel: That's very helpful. So I'll add a pointer in the issue,
   and say we require support for unicode control characters

   Chris: Is unicode control characters what the i18n group say
   they dislike?

   Atsushi: Assigning the attribute as markup will help with
   semantics, but if we use the unicode code points, there's a
   need to understand the unicode characters itself. Could be a
   processing overhead. I think that's the root cause

   [20]How can mixed direction ltr and rtl be specified in
   metadata elements w3c/dapt#164

     [20] https://github.com/w3c/dapt/issues/164


   Nigel: Other things we've received on DAPT, I got some instant
   feedback on wide review from APA WG
   … They said DAPT looks like a typo, as it says "A DAPT", and
   ADAPT refers to something else. So people suggesting it needs a
  name change
   … I'm not completely convinced I agree with their conclusion. I
   tried to search for ADAPT in the context of dubbing and audio
   description
   … But didn't find anything. There's a WAI-Adapt, that used to
   be called the "personalisation task force". It's not a document
   or a spec, but they were sensitive to that
   … Not sure what action to take. Maybe edit the start of that
   sentence

   cpn: The title is clearly the Dubbing and Audio description
   Profile - perhaps if it is spelled
   … out at first, rather than jumping into the acronyms, that
   would help.

   Nigel: We could also add a pronunciation note, as we read it as
   D-A-P-T, not "dapt"

   Matt: Reminds me of EBU-TT ;-)

   [21]APA WG feedback - name looks like a typo for ADAPT
   w3c/dapt#167

     [21] https://github.com/w3c/dapt/issues/167


    Support within workflowType for generic script origination
    [22]w3c/dapt#169

     [22] https://github.com/w3c/dapt/issues/169


   github: [23]w3c/dapt#169

     [23] https://github.com/w3c/dapt/issues/169


   Matt: I looked at some of the detail in the spec. We have been
   thinking that a structured script file we can commission people
   to produce, e.g., third party, would be a useful starting point
   for subtitles for deaf and hard of hearing, and dubbing and
   translation workflows

   Nigel: yes, daptm:workflowType

   Matt: There's a workflow type property. It's mandatory, either
   dubbing or AD. When we commission one of these, it could also
   be used for subtitles for deaf and hard of hearing and for
   translation subtitles as well as dubbing
   … At the moment, we'd mark it up as dubbing, but that would be
   erroneous
   … We don't necessarily know which of the subtitling, dubbing,
   or translation subtitling it might need to flow through. It
   could be one or all three

   Nigel: Are you proposing a new value for workflowType?

   Matt: I think so, but don't know what I'd call it

   Nigel: Would transcription work?

   Matt: It needs to be something generic like that. Depends
   whether you see it as describing the workflow or describing
   what's in the document
   … For commercial reasons, we might not want the third party to
   know it's being used for dubbing if they're not been
   commissioned to do that work

   Nigel: That's interesting

   Matt: Was there a view on whether the workflow is describing
   what it contributes towards?
   … That was my reading of it

   Nigel: Yes. I can see that being helpful
   … Any other thoughts on this?

   SUMMARY: Helpful to clarify if worfklowType is intended to
   capture current state or end outcome; adding a transcription
   value could be commercially useful for some user groups.

    Registries

   Nigel: A long time ago, I created a boilerplate registry, in
   the TTWG repo PR 243

   github: [24]w3c/ttwg#243

     [24] https://github.com/w3c/ttwg/pull/243


   Nigel: As there's been no comments, and all comments resolved,
   so I propose to merge the PR, and then create registries based
   on this: two for DAPT
   … Need to work out how, either as separate documents or
   directly inside DAPT
   … Unless you want more time to review, I propose merging

   cpn: The only thing in my mind was about editor's drafts of
   draft registry status,
   … in Respec. Did you make any progress with that?

   Nigel: I didn't do anything about that!
   … It's a good point

   Chris: It's a separate issue.

   Atsushi: I suppose WebCodecs registry is using slimline
   publication that we are using for DAPT,
   … where they auto-publish to /TR on merge
   … If so, there's no difference between ED and the published one
   on /TR so the state of ED for Draft Registries
   … is not needed.

   cpn: Here, you haven't decided if the Registry is a separate
   document or within the spec itself.

   Nigel: Yes

   Chris: No need to delay it on my account then - that was my
   only question.

   Nigel: Anyone else?

   group: No

   SUMMARY: TTWG call 2023-07-20: merge this pull request

  Meeting Close

   Nigel: Thanks everyone, we're over-time - let's cover any
   TPAC-related issues offline.
   … [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