{Minutes} TTWG Teleconference 2023-05-25

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


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

25 May 2023

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

      [2] https://www.w3.org/2023/04/27-tt-minutes.html

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

      [4] https://www.w3.org/2023/05/25-tt-irc


Attendees

   Present
          Andreas, Atsushi, Cyril, gary, Matt_Simpson, Mike,
          Nigel, Pierre

   Regrets
          -

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This Meeting
    2. [6]IMSC-HRM
    3. [7]DAPT
         1. [8]Collaborative editing or partial editing - do we
            need "unfinished" state? w3c/dapt#52
         2. [9]AD embedding issues
    4. [10]Discussion: Any requirement to support tts:fontVariant
       in IMSC, and allow all-small-caps?
    5. [11]TPAC 2023 planning.
    6. [12]Meeting close

Meeting minutes

  This Meeting

   Nigel: Agenda for today:
   … IMSC-HRM
   … DAPT
   … Discussion of potential need for font-variant: small-caps
   … Any TPAC 2023 suggestions
   … Is there any other business? Or items to make sure we cover
   within those topics?
   … Quick intro to Matt

   Matt_Simpson: You may remember me from Red Bee Media / Ericsson
   - I'm now at ITV doing a similar role
   … and particularly interested in DAPT.

   Cyril: Welcome!

   Nigel: I've invited Matt as an observer today, from the formal
   meeting attendance perspective.

   group: [brief introductions]

  IMSC-HRM

   Nigel: Reminder that I sent a Call for Consensus to transition
   to CR

   [13]CfC email for transition of IMSC-HRM to CR

     [13] https://lists.w3.org/Archives/Public/public-tt/2023May/0007.html


   Nigel: Runs until 2nd June.
   … I've had a couple of messages of support.
   … No signals against transitioning to CR.

   [14]Pull Request including CR Exit Criteria

     [14] https://github.com/w3c/imsc-hrm/pull/59


   Nigel: If you have any issues with the CR Exit Criteria please
   comment on the pull request.
   … Encourage everyone to review them for themselves and in the
   context of the current TTWG Charter.
   … Any questions or points on this?

   Cyril: The CR pull request has links to GitHub issues - is this
   still okay at this stage?
   … I thought the CR was supposed to be almost final.

   Nigel: Even Recs have GitHub links

   Pierre: One of those is because of an at-risk feature, where we
   were encouraged to use a GitHub issue.
   … The other was something that we hope to answer conclusively
   during testing.
   … We use GitHub as a way to track those, and were encouraged to
   do that.
   … As opposed to doing it offline or in the implementation
   report.

   Nigel: Atsushi says via IRC: we need to mark feature as
   at-risk, if any, but no need to resolve all issues, for CR

   Cyril: That answers my question!

   Pierre: My plan is, as soon as the CfC concludes, hopefully
   positively, I'll put together test content,
   … and a call for tests, and I will update the sample web app
   that's based on the open source code,
   … to match the CR.

   Nigel: We don't have a test suite now, just an empty repo.

   Pierre: Correct. I wanted to wait until confirmation that we
   would progress before working on that.

   Nigel: Any more on IMSC-HRM?

   no

  DAPT

   Nigel: We've been merging PRs in the normal way.
   … In our last Editor's meeting we marked some issues as needing
   to be resolved before CR.
   … Any open PRs now?

   Cyril: Yes, yours

   Nigel: Oh yes, completely editorial, needs a review.

   Cyril: I will check it.

   Nigel: On the list of steps, we can confirm that we have
   auto-publication to WD on merging PRs to main branch.
   … It's happened several times!
   … Thank you Atsushi for making that work.
   … I have not yet requested HR or WR from liaisons.
   … I opened a tracking issue for us for that

   [15]Prepare for Horizontal Review w3c/dapt#144

     [15] https://github.com/w3c/dapt/issues/144


   Nigel: One obvious target for a liaison would be EBU, and I did
   present the DAPT spec to EBU in a remote meeting.
   … That presentation generated some useful feedback which I have
   added to issues where needed.
   … The main thing is tracking of work in progress as well as
   completed deliverables.
   … In other words, support for organisation making DAPT
   documents, during their preparation

   Mike: Should we send to ATSC and CTA too?

   Nigel: We have a list of liaisons, and we can send to others
   even if not on that list.

   Mike: The discussion of audio description has warmed up so it
   might be helpful to share with them.

   Nigel: Thanks, I will.
   … If I need any contacts perhaps I'll ask you Mike.

   Matt_Simpson: I think this is a very useful thing to have, both
   from audio description to move away from
   … proprietary formats, and also for use as structured scripts
   for other use cases.
   … I've wanted to move away from PDFs and Word documents for
   inbound script data for a while.

   Nigel: I received more positive feedback from someone else in
   EBU too.

   Cyril: Can we look at #52 since Matt is here.

   Nigel: Just to note, on IRC Atsushi mentioned that we can
   request transition to CR even before all HR GitHub tracking
   issues are closed.
   … Worth noting, especially in the context of IMSC-HRM where
   there's one i18n issue still open I believe.

    Collaborative editing or partial editing - do we need "unfinished"
    state? [16]w3c/dapt#52

     [16] https://github.com/w3c/dapt/issues/52


   github: [17]w3c/dapt#52

     [17] https://github.com/w3c/dapt/issues/52


   Cyril: This issue is about possibly tracking state changes into
   a document.
   … Thank you Matt for commenting on it.
   … I'm asking myself and my colleagues if there is a need for
   interoperability in tracking changes
   … while editing?
   … I'm not sure for example if we would go between authoring
   tools where interop is needed to signal unfinished editing.
   … The other thing is: possibly it could be done externally to
   the document, in a version control system
   … or asset management system.
   … At Netflix the need we identified is to see what delivery it
   refers to.
   … For example if a script is received, the original media
   changes and you need to get another one.
   … It's about tracking multiple finished documents pointing to
   different related media objects.
   … We added some text about identifying related media objects
   recently.
   … You could use that, as well as additional proprietary data in
   other namespaces.
   … I'm looking for use cases where interop is needed between
   tools for fine-grained change tracking.

   Matt_Simpson: Quite often we will be asked to reversion or
   modify a subtitle or caption file based on the results
   … of compliance edits or a localisation process.
   … It's very useful for the translators, captioners, subtitlers,
   to be driven to the changed elements rather
   … than working out for themselves where the differences in the
   media are.
   … It can be as simple as an edit to remove a section, or
   replacement of expletives, or some other editorial change.
   … I agree, we could do it as an external diff process.
   … From our point of view there is value in it travelling within
   the document.
   … It does not need to be particularly complex.
   … I can see arguments against keeping multiple versions in one
   file.
   … But just indicating what had been edited most recently would
   be useful.
   … We get around this now by exporting Edit Decision Lists and
   pointing humans to the changed timecodes.
   … Does that help?

   Cyril: Yes, it helps, it's very similar when you mention ETL.
   My colleagues are using OpentimelineIO to do the same thing.
   … I still wonder how we identify the latest edits in the
   document.
   … Have an iteration number on each script event, and increment
   all the touched events every time you edit?
   … I would need to see a proposal. I'm not opposed.
   … What Nigel suggested initially, to use ScriptType at event
   level, I don't think it covers your use case.

   Matt_Simpson: No, for me it's almost like a "dirty" flag - what
   has not been seen before in this file.

   Cyril: How would you track deletions then?

   Matt_Simpson: True, that's equally valid.

   Andreas: Question to Matt - is this particular for DAPT, or for
   other TTML documents?

   Matt_Simpson: It would count for other TTML documents, but
   workflow-wise if we were to use DAPT as an
   … inbound script and we have multiple versions sent to us, it
   would be useful to know what is different,
   … i.e. the intention of the edit.

   Cyril: I agree with that. The current thinking is to carry
   top-level metadata in the form of a change log,
   … but not with a fine-grained approach.

   Matt_Simpson: If we want to save human time, we would want to
   direct the person to the changed part rather
   … then having them hunt for it.
   … A DAPT document could be the input to a process, where an
   IMSC document might be the output,
   … from a lifecycle point of view.

   Cyril: My suggestion is to continue the conversation offline
   with examples. Do others share the same use case?
   … Is this a v1 thing or can it be deferred for now? There are
   options.

   SUMMARY: Continue discussing offline

    AD embedding issues

   Cyril: We're looking for feedback about the multiple ways to do
   the same thing with managing
   … audio recordings - embedding, referencing, etc.

   Nigel: Yes, there are lots of issues embedded in the document.

   Cyril: It's #113, #114, #115 and #116 if people want to look at
   them.

   Nigel: In general when we ask "do we need all the ways TTML2
   has to offer" the answer is "probably not"
   … but I need to have some guidance to help select the best
   options here in this case.

  Discussion: Any requirement to support tts:fontVariant in IMSC, and
  allow all-small-caps?

   Nigel: I was recently re-examining the FCC caption
   customisation requirements and saw that one of the
   … options for font appearance is curiously different from all
   the others!
   … There's a requirement there for all small capitals.
   … In the past when we've discussed this I think we concluded
   that the requirement could be met
   … by providing a specially designed font.
   … I'm sure that's true, but there's a much easier way nowadays.
   … That's to use the CSS font-variant property, specifically the
   one that allows all-small-caps,
   … and that will cause a conformant user agent to choose the
   small capitals glyph variants in whatever
   … font is chosen.
   … It's simpler for the implementer because they don't need a
   special font, and it means that in principle
   … the user can choose orthogonally the font face, e.g. serif,
   sans-serif etc. and whether to use all caps or not.
   … Current state is TTML2 does not support this property value
   in tts:fontVariant,
   … and IMSC does not support tts:fontVariant at all.
   … I wanted to raise this in case others have also hit this
   curious requirement.

   Pierre: First time I've heard about it.

   Mike: The FCC suggests it be a separate font, and the font it
   uses as an example is all caps of course,
   … but the capitalised letters are actually larger.
   … I don't know if you get the same result with the CSS
   property.
   … It might be a clever way to address it.
   … I'm not aware of anyone who has actually implemented this,
   independently of TTML.
   … Not sure where the best balance of energy is spent.
   … If you use Engravers Gothic then it has an example.
   … I'm not opposed, but concerned about putting a lot of energy
   into a little used feature.

   [18]MDN CSS font-variant-caps page

     [18] https://developer.mozilla.org/en-US/docs/Web/CSS/font-variant-caps


   Nigel: Thanks for the link there Pierre. That's great - it
   shows that the `small-caps` value does indeed
   … present actual capital letters larger than lower case
   letters, which are also capitalised.
   … I'm not sure if this is allowed in WebVTT - I assume not?

   Gary: I'll check
   … ... It doesn't have it, no.

   Nigel: This strikes me as a great use case for the new Process
   that allows us to add delta features
   … without the full review cycle of entire specifications.

   Mike: Could be worth discussing with CTA too, to get
   manufacturer's views.

   Nigel: That would be useful, yes, thank you.

   Matt_Simpson: Using all capitals goes against most
   accessibility guidance - it makes text harder to read

   Mike: Is there a link to where it says that?

   Matt_Simpson: I can share that later.

   Mike: That'd be helpful, thanks.

   Nigel: Of course the property is not needed in the captions
   document itself - as a customisation implementation,
   … it can be applied to the render area container and gets
   inherited.
   … Summary for this topic today is that more input is needed.

  TPAC 2023 planning.

   Nigel: Any thoughts of agenda topics for TPAC? This is a
   placeholder agenda item.

   group: none so far

  Meeting close

   Nigel: We've concluded our agenda, let's adjourn. Thank you
   everyone. [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [19]scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).

     [19] https://w3c.github.io/scribe2/scribedoc.html