{Minutes} TTWG Teleconference 2024-03-28

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


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

28 March 2024

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

      [2] https://www.w3.org/2024/03/14-tt-minutes.html

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

      [4] https://www.w3.org/2024/03/28-tt-irc


Attendees

   Present
          Andreas, Cyril, Gary, Nigel, Pierre

   Regrets
          Atsushi

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]IMSC-HRM AC Review of PR
    3. [7]DAPT
         1. [8]Changing workflowType to alternativeFor
         2. [9]Add informative section about mapping from TTML to
            the DAPT data model w3c/dapt#216
         3. [10]Other Pull requests
    4. [11]Next meeting - time will be adjusted
    5. [12]Meeting close

Meeting minutes

  This meeting

   Nigel: Today we have IMSC-HRM AC Review of PR,
   … and DAPT issues and pull requests.
   … Any other business, or points to make sure we get to?

   no other business

  IMSC-HRM AC Review of PR

   [13]Poll results

     [13] https://www.w3.org/2002/09/wbs/33280/202402-PR-IMSC-HRM/results


   Nigel: [summarises results]
   … The poll closes today
   … I think there have been some attempts to get more responses,
   from various people,
   … so thank you for that.
   … From what I can see, it appears to be a formality to move to
   Rec from this, as it stands.
   … Obviously we don't have Atsushi to speak for the team.

  DAPT

   Nigel: I've been busy since last call, and we should take a
   look.

   [14]DAPT issues labelled for agenda

     [14] https://github.com/w3c/dapt/labels/agenda


    Changing workflowType to alternativeFor

   github: [15]w3c/dapt#217

     [15] https://github.com/w3c/dapt/pull/217


   [16]Replace workflowType with alternativeFor w3c/dapt#217

     [16] https://github.com/w3c/dapt/pull/217


   Nigel: Related issue:

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

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


   Nigel: The problem we had was that workflowType, being
   restricted to audioDescription or dubbing,
   … didn't actually work all that well for everyone in the chain.
   … For example it didn't cover things like production of a
   transcript and/or translation
   … with the intent of using it for subtitles.
   … So I replaced it with alternativeFor, which is a description
   of which components of the related media
   … the document contents represent, or are an alternative for.
   … It's a comma separated list, with four possible values in the
   list.
   … Those are dialogue, nonDialogueSounds, visualNonText and
   visualText.
   … Very few other changes were needed.
   … Two questions from me:
   … 1. Since nothing depends on this list, at present, should the
   values come from a Registry Table?
   … 2. Should we keep this as a mandatory attribute, or can it be
   optional?

   Cyril: I don't disagree with how it's done.
   … Wondering if the term "alternativeFor" is the right term. I
   think we had "represents" before.
   … Why this choice?

   Nigel: Yes, I thought someone didn't like "represents", maybe
   you Cyril?!
   … Also, I wanted to tie it in with accessibility language and
   terminology a bit more closely,
   … so that people in that world are comfortable with what this
   is doing.
   … I don't mind changing it to a different name.

   Andreas: When I read the term, I was wondering what it means
   too - it's not intuitive.
   … If we go in this direction, "represents" as a term is more
   accessible.
   … Also, in the approach, I see the benefit of it, and the goal
   to separate the different uses more clearly.
   … But it kind of breaks with terms used in the industry like
   dubbing and audio description.
   … For that, they need to get their head around it. That's my
   first impression.

   Nigel: I did add a note about typical values for those use
   cases but I get what you mean.

   Cyril: As you indicated, "alternative" is a key word for
   accessibility. I need to think about it.
   … I'm not sure a transcript is really an alternative - is the
   transcript used to produce dubbing or AD really an alternative?

   Nigel: I'm not glued to this - I've explained my reasoning, but
   the reasons aren't strong.

   Cyril: Regarding the question about registry, I'm not sure.
   … It's good for implementation and extensibility to use a
   registry.
   … But the way you've structured the keywords, it feels like it
   covers the entire space,
   … with the union representing everything.

   Nigel: Maybe, but there could be something else.

   Cyril: You might want more granularity - text could be signs,
   time and dates etc.
   … So now I think about it, using a registry is better probably.

   Nigel: OK

   Cyril: The last question was about making it optional vs
   mandatory.
   … What is the use case where you wouldn't know what your script
   represents?
   … It may evolve, but at any point in time you should know what
   the script represents.
   … so I still think it should be mandatory.

   Nigel: I'm happy to take the action to turn the
   content-descriptor values into a Registry Table.
   … The other possible action is renaming it to "represents" or
   some other thing.

   Cyril: [reads the original issue] I don't think I have a
   problem with "represents"

   Nigel: OK, any other thoughts before I give myself the action
   to change it?

   no other comments

   SUMMARY: @nigelmegitt Change `<content-descriptor>` to be a
   Registry Table; change name to "represents".

    Add informative section about mapping from TTML to the DAPT data
    model [18]w3c/dapt#216

     [18] https://github.com/w3c/dapt/issues/216


   github: [19]w3c/dapt#216

     [19] https://github.com/w3c/dapt/pull/216


   Nigel: Quite a big change, new informative section added,
   mostly as discussed in the issue and our previous call.
   … Introduces some implementation considerations for ingesting
   generic TTML2 documents that are also
   … DAPT conformant, which might not have a 1:1 mapping to the
   DAPT Data Model.
   … My biggest question is: is there anything in here that anyone
   thinks needs to be normative?

   Cyril: Thank you for this, I started to review it, and that was
   my biggest question.
   … You phrased it that there is no requirement for DAPT
   implementations to perform the task...
   … which is what? Parsing the DAPT document into a DAPT Data
   Model?

   Nigel: It's "attempting to populate a data structure
   corresponding to the DAPT data model from any conformant DAPT
   document"

   Cyril: Why isn't that a requirement?

   Nigel: Because the only normative requirement is that a
   processor conforming to the TTML2 profile can process
   … the document.

   Andreas: But a DAPT processor should be able to do it?

   Nigel: That's not a thing though, a "DAPT processor"

   Andreas: You ask if there's any concern about making this
   informative, and I think I mentioned in the last
   … call that I have some questions about whether that's enough.
   … My simple thinking: 2 implementations that implement DAPT,
   are DAPT implementations.
   … If they're parsing DAPT-conformant TTML documents they should
   have the same result,
   … so that there's interoperability. If you leave this open to
   be implementation dependent,
   … that could be a problem. Could they come up with different
   results?
   … This would be my main question when I come to review it.

   Nigel: The reason I don't think that's a problem is because the
   semantics for processing the document
   … are normatively defined by TTML2.
   … Where we might need something normative would be if we wanted
   to have a fixed mapping back from
   … every possible DAPT conformant document into the DAPT data
   model.
   … Because that data model is defined by this spec, there can't
   be normative requirements for doing that within TTML.

   Andreas: Again, maybe it's simple how I'm thinking, but a
   possible implementation would be to make the DAPT
   … data model the internal data model, and handle the document
   accordingly.
   … If two implementations do this I would assume they come up
   with the same values.

   Cyril: I'm wondering what are the classes of TTML processor
   that could do something meaningful with
   … a DAPT document. For example if I have a TTML authoring tool
   and I load a DAPT document,
   … I don't think the generic tool would be able to do any edits
   and guarantee that the output would
   … remain conformant with the profile. Are you thinking that a
   generic authoring tool would see what is
   … permitted or prohibited and constrain its UI to do only
   what's permitted?
   … The bigger question: yes, a DAPT document is a TTML document,
   but is that useful for having a TTML
   … processor process the document. I think we need tailored DAPT
   processors.
   … They will do meaningful edits to the document.
   … Just knowing they are TTML documents does not seem to be
   sufficient to do meaningful edits.

   Nigel: A generic TTML2 presentation processor that supports
   audio features should be able to
   … play back a DAPT audio description script for example.
   … A generic TTML2 transformation processor can observe the
   profile feature and extension requirements
   … and decide if it supports the required features or not, and
   if it doesn't, presumably all bets are off, in terms of
   … what it does.
   … My thinking is that the profile constraints manage this for
   us.

   Cyril: On the playback side, I agree.
   … A generic TTML processor could present a DAPT document
   without knowing about the DAPT data model, for sure.
   … For a generic TTML transformation processor, that seems like
   a theoretical concept, so I wouldn't worry about these.
   … So I think we should introduce a DAPT processor, which does
   not necessarily support generic TTML processing,
   … but does support DAPT Data model processing.
   … Then that section that you wrote can have SHALL statements
   that only apply to this class of processor.

   Nigel: This is for validators, or editors?
   … I have another concern, which is extensibility of DAPT, and
   forwards/backwards compatibility.
   … If we do as you suggest Cyril, how do we avoid introducing
   compatibility issues in the future?

   Cyril: Can you repeat the example?

   Nigel: If we introduce a new entity into the data model in the
   future, for example. E.g. a Script Event grouping
   … structure. Wouldn't that break this new class of DAPT
   processor?

   Cyril: Generically, if we define a new entity that does not
   exist today at all, the old data model processors
   … would ignore it, but the grouping one is a special case - I
   think that's what you've done, to identify
   … what is a script event wherever it is in the document.

   Nigel: I think the answer will hinge on whether we really need
   a DAPT processor class.
   … It would be helpful to get review comments on the pull
   request.

   Cyril: When I looked at your example, today we seem to rely on
   the xml:id to decide if a div might be a
   … Script Event. I wonder if we should have a ttm:role that says
   "script event" more explicitly.
   … Then the DAPT processor just finds this, and that's it.
   … How deeply nested in the TTML shouldn't matter.
   … Other things can be pruned.
   … You do whatever you want with the rest. That seems simpler to
   me.

   Nigel: If we do that then we need structural constraints, that
   we currently don't list.
   … For example what if a div marked as a Script Event contains
   another div marked as a Script Event.

   Cyril: Yes, we could have constraints about that.

   Nigel: Yes, that's an option.
   … My overall direction here is steered by "less is more", and
   if we don't need a DAPT Processor, say,
   … then we shouldn't create one. Of course maybe it is actually
   important, and we should define it.

   Cyril: The original question is what a processor should do if
   it encounters a DAPT document with
   … contents that go beyond what would get directly made by a
   mapping from this version's DAPT Data Model.

   Nigel: Yes.

   SUMMARY: Reviews to continue, revisit this after more thought
   and discussion.

    Other Pull requests

   Nigel: I opened two more pull requests, one to add at-risk
   features, the other to
   … define empty Text and note the use case for omitting Text
   objects.
   … I see they've recently been approved - thank you!

  Next meeting - time will be adjusted

   Nigel: Next meeting, and going forwards until next DST switch,
   the UTC time of the call will be adjusted
   … to be an hour earlier, as previously discussed. Back to the
   "usual" local time, except in places without DST.

  Meeting close

   Nigel: Thanks everyone, we're just about at time. [adjourns
   meeting]


    Minutes manually created (not a transcript), formatted by
    [20]scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

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