{Minutes} TTWG Teleconference 2025-02-27

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


In plain text:

   [1]W3C

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


                Timed Text Working Group Teleconference

27 February 2025

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

      [2] https://www.w3.org/2025/02/13-tt-minutes.html

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

      [4] https://www.w3.org/2025/02/27-tt-irc


Attendees

   Present
          Atsushi, Cyril, Gary, Nigel, Pierre

   Regrets
          Andreas, Chris_Needham

   Chair
          Gary, Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]DAPT
         1. [7]Implementation Report
    3. [8]IMSC 1.3
         1. [9]Update namespace documents w3c/imsc#589
         2. [10]Wording of example for WCAG SC 1.1.1 w3c/imsc#551
    4. [11]Meeting close

Meeting minutes

  This meeting

   Nigel: Today we have some DAPT and IMSC stuff
   … Any other business, or points to make sure we cover within
   those topics?

   Gary: AOB for timezone - next meeting will get us into the DST
   shenanigans
   … March 9 in the US, so 3 or 4 weeks difference

  DAPT

   Nigel: No issues or pulls listed for the agenda.
   … We do have a transition request.
   … for CR publication.

   [12]Transition request for DAPT

     [12] https://github.com/w3c/transitions/issues/693


   Atsushi: The decision should be made on Friday 28th February.
   … I cued myself to prepare for a March 5th publication.

   Nigel: Do you need anything from us?

   Atsushi: No, I may open a PR for the final up to date tweaks
   but I don't believe there is anything
   … to be done by the WG for publication.

   Nigel: I wondered about comms, blog posts etc.

   Atsushi: I should be able to handle those.

   Nigel: For most stuff you will just update the existing CR?

   Atsushi: Yes

   Nigel: Good news, good to get there.

   Atsushi: Thank you for your patience with the formal procedure.

   Nigel: Any questions about this?

    Implementation Report

   [13]DAPT Implementation Report

     [13] https://www.w3.org/wiki/TimedText/DAPT_Implementation_Report


   Nigel: I had the action to update it to add recently added
   features and at risk features.
   … I have now done that.
   … The added feature was #descType.
   … I started looking again at the XSD earlier, and have hit an
   error I don't understand yet.
   … The next big step for us is to create test material for all
   the DAPT features.

   Cyril: FYI re DAPT.
   … Last week I attended Mile High Video in Denver.
   … There were a few presentations about dubbing, mainly
   academics.
   … For example changing the speed of speech to accommodate
   dubbing.
   … I was able to promote DAPT and encourage implementation
   feedback.

   Nigel: Sounds good!

  IMSC 1.3

   Nigel: One pull request flagged for the agenda, re namespaces.
   … Anything else to cover?

   Pierre: We could do #551 too.

    Update namespace documents [14]w3c/imsc#589

     [14] https://github.com/w3c/imsc/issues/589


   github: [15]w3c/imsc#589

     [15] https://github.com/w3c/imsc/pull/589


   Nigel: Two things to cover.
   … First is can we publish the namespace documents?

   Atsushi: I have not reached a conclusion myself about what
   should be in the namespace documents.
   … For this moment what I can do is open pull requests to the
   W3C namespace document repo,
   … and ask for review or comment or suggestion etc. on the PR.
   … I am not sure if there should be any negotiation or knowledge
   of the existing documents,
   … but I personally have not enough knowledge at this moment.
   … I am now just tending to opening the pull request and asking
   for review including from plh and others
   … for meeting namespace documents.
   … If you don't have any comments about the contents then let me
   get comments from the wider
   … team including plh or others who worked on DTD and XML
   before.

   Nigel: OK

   Atsushi: I understand that the definitions are not necessary
   for us since there is almost no tool
   … who are querying the namespace documents on the fly.
   … I heard there are some toolchains e.g. for RDF and JSON-LD
   that access a namespace definition file
   … every time they have to validate something. If there are
   tools like that in IMSC space...

   Pierre: There's no such tool

   Atsushi: I believe we just need some static HTML.

   Pierre: What do you need to make progress?

   Atsushi: To be honest this is the first time I'm updating
   namespace documents.

   Nigel: See for example the TTML2 one:

   [16]https://www.w3.org/ns/ttml/


     [16] https://www.w3.org/ns/ttml/


   Atsushi: Best I can do is learn from existing documents.

   Nigel: This is maybe much simpler than you are thinking!
   … It just needs to be a resource you get when you dereference
   the namespace URL.

   Atsushi: Let me open the pull request

   <atsushi> [17]himorin/w3c-ns#1

     [17] https://github.com/himorin/w3c-ns/pull/1


   Nigel: This is where we got to 1 month ago when we discussed
   it. The action is the same.

   Atsushi: Let me try and I will consult if I get any comments.
   … I can prepare the similar thing for IMSC immediately.
   … If this one for DAPT is accepted then I could immediately
   create the IMSC one.

   Nigel: I think the IMSC one is more urgent.

   Atsushi: I will prepare one for IMSC in parallel to this.

   Nigel: OK, then the next thing to consider is the substantive
   content of the PR.
   … I had two proposals. One was to add fragment IDs.

   Pierre: [Omitting fragment identifiers] was by design.
   … The fragment identifier is not part of the URI, it's a UA
   behaviour.
   … As I recall the discussion many moons ago, the fragment is
   not part of the namespace when you
   … resolve it.
   … This is all because we are using URIs that happen to be HTTP
   URLs, and the fragment is not part of the URI
   … that is being dereferenced.
   … The HTTP GET request does not include the fragment ID, it's
   only the UA that looks for that id
   … when the document is loaded.

   Nigel: Then I would change my proposal to list the namespaces
   with fragment IDs in the HTML documents.

   Pierre: That's needless duplication of the Namespace section in
   the specification.
   … The sole purpose is to get a reference back from the
   namespace into the defining document.
   … Once you get that non-machine-readable namespace document,
   you get told where to go to find
   … the meaning of the namespace requested.
   … I don't want to duplicate. I want these documents to be as
   simple as possible.

   Nigel: I think it's a weird user journey to put in one of the
   namespaces from the IMSC spec,
   … then get taken to a page that says "this spec defines that
   namespace" but doesn't actually list
   … any of the strings in the spec, which all have fragment
   identifiers.

   Pierre: We could change the wording to encompass all fragment
   identifier suffixes too.

   Nigel: That could work, yes.

   Pierre: We need to get the correct wording for that concept.

   Nigel: OK, should we wordsmith that now?

   Pierre: Probably should, since we're here and it's the last
   issue.

   Nigel: Now we have:
   … "The namespace [18]http://www.w3.org/ns/ttml/profile/imsc1 is
   specified by ..."

     [18] http://www.w3.org/ns/ttml/profile/imsc1


   Pierre: [looks up RFC3986]
   … "secondary resource" is one term used in RFC3986.
   … "The fragment identifier part allows ..."

   Nigel: So we could say "The namespace [19]http://www.w3.org/ns/

   ttml/profile/imsc1 and all secondary resources identified by
   additional fragment identifiers are specified by ..."

     [19] http://www.w3.org/ns/ttml/profile/imsc1


   Pierre: Yes that's good
   … [implements that in the PR]

   Pierre: You had another orthogonal concern.

   Nigel: Yes, mapping the versions in namespaces to the IMSC
   document versions,
   … IMSC 1.1 Image namespace is an outlier pointing to IMSC 1.2
   spec.

   Pierre: We want to point people to 1.2 because we improved the
   spec document compared to 1.1
   … even if we didn't make substantive changes.

   Nigel: OK that's a strong enough argument for me.

   Pierre: And you were a strong proponent of pointing people to
   the latest version of the spec.

   Nigel: True!

   Pierre: I agree it's annoying to have a version number that
   points you to a spec with a different version
   … number that then points you back to another one!

   Nigel: OK I think we have enough to resolve on this.

   SUMMARY: @himorin to open pull request to implement this PR
   change; Keep the existing version mappings as in this PR now;
   update the IMSC namespace doc to include secondary resources.

   Pierre: I've done the secondary resource change.

   Nigel: I've approved it.

   Pierre: Should I merge it?

   Nigel: Yes merge it, and if there's feedback let's handle in a
   different ticket.

   Pierre: Thank you everybody

   Atsushi: I can use this merge to support this with W3C team in
   discussions if needed.

    Wording of example for WCAG SC 1.1.1 [20]w3c/imsc#551

     [20] https://github.com/w3c/imsc/issues/551


   github: [21]w3c/imsc#551

     [21] https://github.com/w3c/imsc/issues/551


   Nigel: I raised a suggestion to resolve the APA comment by
   removing Image Profile from IMSC in 1.3

   Pierre: I'm not philosophically opposed to this.
   … I'm not sure it's the best thing, it would require time to
   inform the community,
   … and I'm not sure we have the time this time around.
   … That's why I'm not super excited.
   … But for a later iteration, we should probably open an issue
   specifically on this,
   … so that we remember it for v.next, but for now just stick to
   revising the note, which I think is great.

   Nigel: Ah, good that you liked the proposal.
   … What kind of conversations do we need to have with the
   community about this?

   Pierre: We need to tell people we are stopping work on image
   profile.
   … But we're also saying IMSC 1.3 might be a version we can
   never obsolete, because it
   … is the last version supporting Image Profile.
   … We have to remember that the last version of IMSC containing
   Image Profile should not be
   … obsoleted because even though it might not be up to date for
   Text Profile, for Image Profile
   … it might be the right one.
   … Or we split the documents.

   Gary: Is it possible to add a non-normative note to the Image
   Profile section saying we're considering
   … removing it from future editions.

   Pierre: I found one of those notes in the current version of
   the document and we never acted on them.

   Gary: Maybe update the note to make it more prominent and
   follow through.
   … That could be the signal to notify the community.

   Pierre: I think we should just talk about it.

   Gary: That too. It would be good to have it in the spec.
   … An "official" documentation for it.

   Pierre: If it helps you, I'm happy to do it.
   … I think we should post a message on the SMPTE, W3C, EBU,
   DASH-IF reflectors etc.

   Gary: Community outreach is more important.

   Pierre: If we get no feedback maybe we should do it now.

   Gary: I guess what are the timelines for IMSC 1.3 and how long
   do we want to wait.

   Pierre: Someone who really cares about it should respond
   quickly.
   … If we compose a standard message that says we're considering
   no longer maintaining
   … IMSC Image Profile and it will be forever the one in IMSC 1.2
   or IMSC 1.3, let us know what you think.
   … And we go to the various groups with that, and convey that
   message, and
   … nobody complains and everyone supports, I think I'd be
   comfortable to remove it.
   … But the second someone says they use it extensively and want
   to add something, then
   … it sets a longer discussion going. But if nobody complains in
   a defined timeline, I'd be comfortable removing it.

   Nigel: My argument in favour of your proposal Pierre is that we
   have no proposals for any feature changes
   … relating to Image Profile, but we have already diluted it
   somewhat compared to 1.2 by removing the
   … HRM applicability. So anyone currently using Image Profile is
   subject to the HRM constraints,
   … whereas if we keep Image Profile in 1.3 and publish it, then
   it isn't clear whether an Image Profile
   … document meets the HRM constraints or not. So if there's
   industry support, removing Image profile
   … now would be cleaner, and would make 1.2 the last version
   with Image Profile support.

   SUMMARY: @nigelmegitt to open new issue for dropping Image
   Profile, and to open a pull request with proposed note text;
   consider industry messaging offline.

  Meeting close

   Nigel: We're over time - Gary do you have a proposal for the
   DST change?

   Gary: Last time we stuck with UTC so the meeting was an hour
   later in the US.

   Nigel: That works for me if it works for everyone else.
   … [adjourns meeting]


    Minutes manually created (not a transcript), formatted by
    [22]scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

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