{Minutes} TTWG Teleconference 2024-06-20

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


In plain text:

   [1]W3C

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


                Timed Text Working Group Teleconference

20 June 2024

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

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

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

      [4] https://www.w3.org/2024/06/20-tt-irc


Attendees

   Present
          Andreas, Atsushi, Cyril, Matt, Nigel, Pierre

   Regrets
          Ewan, Gary

   Chair
          Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Add section about mapping from TTML to the DAPT
            data model w3c/dapt#216
    3. [8]TPAC 2024
    4. [9]TTML in MP4 MPEG issue
    5. [10]Meeting close

Meeting minutes

  This meeting

   Nigel: Today we have a DAPT pull request,
   … a TTML2 ttm:role issue,
   … TPAC and one AOB so far: TTML in MP4 MPEG issue
   … Is there any other "other business" to cover today?

   no other business

  DAPT

   Nigel: There's one issue on the agenda

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

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


   github: [12]w3c/dapt#216

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


   Nigel: Thank you Cyril for all the review comments.
   … I tried to resolve them but left this on the agenda so we
   could cover the questions that arose.

   Nigel: Re the Script Event identification, thanks for raising
   the issue.
   … Can we tackle it as a separate pull request?

   Cyril: I'm not sure, we may need to do it first because it
   could simplify the algorithm
   … for identifying Script Events and make this pull request
   simpler.

   Nigel: I think my preference would be to finish this one before
   iterating over it again.
   … There's a lot more in this pull request than just that bit.
   … If we end up changing the algorithm significantly I don't
   really mind, but at least we would have
   … a logical development based on what we have now.
   … Is that ok?

   Cyril: Let's see, I need to do a re-review following the recent
   changes.
   … Regarding DAPTv2 and extensibility, we say today that every
   DAPT document must write
   … the DAPT 1.0 content profile designator, which is a promise
   on all the future profiles we may generate,
   … and we're doing that for backwards compatibility in the
   future.
   … I'm not sure if we can hold that promise forever.

   Nigel: Me neither

   Cyril: My point was that "a profile compliant to this
   specification" without mentioning the profile version,
   … could be reworded so it doesn't need to change, a DAPT
   content profile designator
   … rather than forcing the v1.0 designator.

   Nigel: That makes sense, please could you highlight where you
   mean and put a comment about it in the thread?

   Cyril: I'll add that so we don't lose this thought.

   Nigel: The next one is the additional validation steps, should
   I add a hypothetical example?

   Pierre: Wasn't the original issue non-pruning of unsupported
   vocabulary?

   Nigel: Right, this PR brings in the idea that stuff must be
   pruned everywhere outside metadata.

   Pierre: Then there should be a corollary that metadata elements
   should not include metadata derived from
   … the document content, or temporal metadata.
   … We should cast a wide net, to strongly discourage people from
   getting into this trouble, which
   … is not solvable really.
   … My suggestion is, instead of recommending what a downstream
   processor should do,
   … if it encounters a document that contains vocabulary that
   belongs to a profile that is not signalled,
   … to recommend in the first place that metadata that would
   cause that situation should not be used.

   Nigel: That's no problem, we can do that.

   Cyril: I wonder if we shouldn't be more precise in terms of
   what types of processor we are talking about.
   … I.e. presentation processor behaviour, transformation
   processor behaviour, validation processor behaviour etc.
   … Here, if it's a presentation processor, saying SHOULD NOT
   implement is sufficient.
   … If it's a validation processor then you prune vocabulary that
   is not declared in the signalled profile,
   … so this paragraph is not applicable.
   … it's only applicable to transformation processors, right?
   Validation and presentation processors don't fix anything.

   <MattS> apols - I have to head to another meeting...

   Nigel: Processors don't have to be exactly in one class, so we
   can't make opposing rules for a processor
   … that is both a transformation and a validation processor.

   Cyril: If it's doing validation, then these rules apply?
   … If it said "taking steps to fix" the document I would be okay
   with that
   … If you meant that a validation processor might take extra
   steps to validate those features if it wants to,
   … maybe, yes, it's a permission as you said.
   … The sentence seems to be mixing the two parts.

   Nigel: Okay. I've got a clearer handle on the problem here, and
   a couple of actions.
   … Next one is about processors SHOULD NOT implement support for
   features that the document
   … does not claim conformance to.

   Cyril: We should not require implementers to model features.

   Nigel: Should we be clear we mean non DAPT profiles?

   Cyril: You can just know that your implementation supports each
   thing, without modelling features.

   Nigel: Exactly.
   … The implementer can be aware of the features without writing
   software that explicitly models them.

   Cyril: I'll read this again. The term feature could be
   interpreted loosely, it does not have to be something
   … defined in a profile definition.

   Nigel: Right, yes.

   Cyril: If it were treated as an "attribute" rather than a
   "feature" then I see.
   … I guess this is probably fine, let me review it again.

   Nigel: next is nested divs.

   Cyril: [suggests allowing a relaxed TTML representation that
   can have nested divs]
   … In the spec we don't say you cannot have Script Events inside
   other div elements
   … The xpath for Character, say, is really explicit, but it is
   not for Script Event.
   … I'm fine with having a section that says how to go from XML
   to the Data Model,
   … and the section you wrote is fine in spirit, but we don't
   give permission to writers to do it, or it is implicit.

   Nigel: The easy way out is to define a generic grouping
   structure.

   Pierre: Or you could forbid it, I would, if there are no
   semantics for it in the DAPT data model.

   Cyril: But then it means in the future we cannot bring grouping
   in, because a v2 document would not be
   … a compliant v1 document. That's what we're trying to avoid.

   Pierre: That's true. At some point data models have to have a
   scope.
   … Is there any conceivable reason for a script to be contained
   in another script?

   Cyril: No, but other grouping could be possible.

   Pierre: You could put grouping semantics in via other
   mechanisms, like a group attribute.
   … That's more flexible because one script can be in multiple
   groups.
   … Unless the semantic is super strong then you don't need such
   tight binding.

   Pierre: You could say only terminal divs are Script Events

   Cyril: That's the issue I opened this morning, that Script
   Events are identified more clearly.

   Pierre: You're making v1 implementations more complex for a
   hypothetical future.

   Cyril: You're right.

   Pierre: Even in TTML2, a TTML2 doc is a valid TTML1 doc
   technically, but the outcome is never going to be good.
   … e.g. ruby - so too flexible is not always practically
   interesting.

   Cyril: This was the design philosophy, that DAPT should be as
   simple as it can be.
   … Maybe what Pierre is saying is the way forward.

   Nigel: Maybe - I do think there are semantics for divs in the
   future that would be interesting, like shifting timings.

   Pierre: It could mean that a v1 processor would reject a v2
   document
   … In many use cases that's actually a good thing

   SUMMARY: Useful discussion, some ways forward, more thought and
   review needed

  TPAC 2024

   Nigel: TPAC registration is open

   [13]TPAC 2024 page

     [13] https://www.w3.org/2024/09/TPAC/Overview.html


   Nigel: The schedule has us with some meetings on the Monday and
   others on the Friday.
   … Let me know if you think we should ask the organisers to
   shuffle the schedule to accommodate any needs.

   Cyril: Do we need the Friday as a full meeting, or could we ask
   to move to the Tuesday?

   Nigel: Maybe

   Cyril: Just an option

   Nigel: That's for me and Gary to check over and sort out

   Cyril: A page where we put who is coming or not would be useful

   Atsushi: I will be there
   … Please don't forget to register as early as possible. The
   price increases if you're late!

  TTML in MP4 MPEG issue

   [14]Use of edit lists and timed text tracks
   MPEGGroup/FileFormat#40

     [14] https://github.com/MPEGGroup/FileFormat/issues/40


   Cyril: The spec has some gaps about edit lists.
   … It could mean different things to use edit lists, leading to
   different results, unless we do something.
   … I think the text at the beginning tries to be clear enough,
   it's an old issue.
   … I'm trying to see if there's momentum to move clarification
   forward.
   … If you care about TTML in MP4 please express your opinion in
   the issue.
   … I know Nigel did in the past.

   Nigel: I commented in some detail
   … Others agreed, so there's some feedback

   Cyril: MPEG is working in July, so it is possible that we draft
   a change to this text.

   Nigel: Thank you for reminding us about this

  Meeting close

   Nigel: We've gone over time, thank you very much everyone.
   [adjourns meeting]


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

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