{Minutes} TTWG Teleconference 2024-02-29

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


In plain text:

   [1]W3C

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


                Timed Text Working Group Teleconference

29 February 2024

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

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

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

      [4] https://www.w3.org/2024/02/29-tt-irc


Attendees

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

   Regrets
          Gary

   Chair
          Nigel

   Scribe
          nigel

Contents

    1. [5]This meeting
    2. [6]IMSC-HRM
    3. [7]DAPT issues and pull requests for discussion
         1. [8]Clarifying what is normatively permitted in a DAPT
            document
    4. [9]DST changes
    5. [10]Meeting close

Meeting minutes

  This meeting

   Nigel: Today we have IMSC-HRM (PR publication?)
   … DAPT issues and pull requests
   … Upcoming DST changes
   … Anything else for the agenda, or to make sure we cover in the
   topics mentioned?

   no other business

  IMSC-HRM

   Atsushi: PR was published today. End of review is March 28/29
   (depending on time zone)
   … We need to get some AC rep reviews, so please ask your reps
   to submit a review.

   [11]IMSC-HRM Proposed Recommendation

     [11] https://www.w3.org/TR/2024/PR-imsc-hrm-20240229/


   Nigel: That's great news, thank you.
   … Apologies from me that we had a bit of a rocky time getting
   to this point!

   Atsushi: Also apologies from me that I haven't built a proper
   set of materials for final review before I
   … submitted the transition request.

   Nigel: No need, we thought we had done that!
   … Anyway, thank you to everyone for getting us to this point,
   … and reinforce the message - get AC reviews on the WBS poll
   they have received, please.
   … I think this is now out of our hands! Is there anything else
   to say about it?
   … Just one thing from me. In the WBS poll it mentions that
   there is one open issue.
   … In that issue I made a comment proposing to defer taking any
   action, so I don't know if we should
   … say anything about that in the WBS?

   Atsushi: There is no reason to restate that it is not intended
   to be included in this version, because
   … that's implied by PR publication, that there are no more
   changes planned.

   Nigel: OK.
   … Anybody clicking on the link to the issue will see that
   anyway.

   Pierre: Thanks everybody, I will merge the pull request to
   reflect the PR publication.

   Nigel: Thanks.

  DAPT issues and pull requests for discussion

   [12]issues for agenda

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


   Cyril: I wonder if we can aim for a CR date, since we are
   getting very close?
   … We had a list of issues marked as Must Have for CR.
   … We should review and see if they are still Must Have.

   Nigel: Good point. I think the proposal with all of those
   issues marked Must Have for CR
   … is to make them "at risk" features, which is a pull request I
   think I should raise.
   … I think we pencilled in a date for getting to CR before, I
   can't recall when.

   Cyril: Is it reasonable to ask for a CfC at the next meeting, 2
   weeks from now?

   Nigel: Looking at the list of open issues, I don't think we
   have a proposal for all the issues, and I think we
   … need one.

   Cyril: Perhaps we can have an Editors meeting to generate
   proposals on those and see if we can do a CfC in
   … next meeting?

   Nigel: Ok, happy to try for that.

   Cyril: Andreas, any issues to be addressed before CR. Others?

   Andreas: No I don't think so.

   Pierre: I don't have any strong feelings one way or the other
   but my experience is that making changes
   … after CR is a lot harder, or you have to be prepared to do
   multiple CRs, which is probably easier now.

   Cyril: Thank you Pierre. At the same time if we think we're
   going to make a better spec every time we're just
   … delaying.

   Pierre: You're preaching to the choir! It's good to have a
   deadline.

   Atsushi: Making changes after the first CRS: If we add
   substantial changes we need to have a review
   … of the changes before the next CRS or before transitioning to
   PR.
   … Also we need to identify any specific at-risk sections.
   … I'm not sure about the potential changes or developments. I
   don't think we need to mark them
   … as at risk though. In any case, a delta review is not a full
   review, but is usually done over specific
   … changed items. I believe it is not so heavy as first CR
   publication.

   Andreas: I definitely don't want to hold back the publication.
   … I remember we had some issues where we said we may have
   different opinions but we want implementation experience.
   … Do we have to look at these again?
   … Also, when I do my reviews I take time to look over the
   complete spec to see all changes together.
   … In the last weeks and months the spec has changed
   considerably, I'm sure for the better.
   … We need to allow time to make it possible to have a complete
   review.
   … That could be the CfC, I don't know. Just a thought.

   Nigel: There are probably a number of pull requests that need
   to be opened and merged quite soon to deal with some issues.
   … I think they can be rolled into a CfC as well.

   Cyril: I think an editor's call can result in pull requests and
   the CfC can be pending review of them.
   … I don't mind 2 or 4 weeks but I would like to get us started.

   Nigel: Agreed!

   Cyril: I don't think we're missing any features. In the past
   month we've been clarifying things but
   … not adding any features, just making sure things work
   together.

   Nigel: Yes
   … That feels achievable to me. Editor's call tomorrow or next
   week, then PRs out, then CfC for CR publication request.

    Clarifying what is normatively permitted in a DAPT document

   Nigel: Two related comments:

   [13]w3c/dapt#192 (comment)

     [13] https://github.com/w3c/dapt/issues/192#issuecomment-1967324217


   [14]https://github.com/w3c/dapt/pull/158#discussion_r1491466316


     [14] https://github.com/w3c/dapt/pull/158#discussion_r1491466316


   Nigel: The topic here is thus:
   … Right now DAPT defines a data model and a mapping from that
   model into TTML,
   … plus a set of formal TTML features and extensions that are
   optional or required for processors.
   … In issue #192 Clarify language application and inheritance
   model we had a conversation about
   … whether we should say that language is inherited from an
   element that otherwise doesn't look like it can
   … have language specified on it, i.e. Script Event Description
   inheriting language from Script Event
   … The other point is in pull request #158 clarify what spans
   are possible in a text and how they are handled
   … Cyril asked about bidirectional mapping e.g. what if the TTML
   elements representing a Character, contain more than the few
   elements specified in the spec
   … I made a proposal that the TTML2 features and extensions
   dispositions are the normative specification.
   … The other thing I think we should take care about is the Data
   Model section is normative
   … and we may need to be careful about whether the diagram is
   considered normative or not.

   Cyril: I understand the commonality between these two things. I
   think they can still be considered separately.

   Andreas: I think you summarised the main issue from my
   perspective.
   … There is a lot more possible in the syntax representation
   than the data model.
   … That may be confusing for the user. xml:lang is just an
   example. You can use it on body and div
   … but it's not mentioned in the spec.
   … Some people might use it but implementers might ignore it.
   … The relationship between data model and syntax representation
   may need to be made clear.
   … Either say that more might be in the document than in the
   data model,
   … or recommend that people write TTML documents that conform to
   the data model.
   … At least some clarifying text would be useful.

   Cyril: On the xml:lang question I think an easy solution would
   be to allow language on script events.
   … It wouldn't hurt and would make it easy.
   … On the span question, my point in the pull request is that
   the text goes beyond what the rest of the spec does.
   … Instead of saying the data model is represented by, the
   current text says how you go from the representation
   … back to the data model. I think this is the only place we do
   that, so I think that's the question.
   … I understand it's a TTML2 profile, but at the same time the
   idea is it should be simple and people should
   … be able to implement the data model not the whole of TTML2 so
   I wouldn't be against more restrictions
   … to avoid allowing things that cannot be mapped back to the
   data model.

   Nigel: Do you think the data model should be normative?

   Cyril: I thought it was?

   Nigel: We generally avoid normative language in the data model,
   and put it mostly in the representation.

   Cyril: I recognise we are doing two things at the same time,
   and its a recipe for mismatch.
   … We should strive to make them match but I agree with
   Andreas's point we should recommend adhering to the
   … model but strictly speaking be prepared a document that goes
   beyond the data model because the TTML2
   … syntax permits it.

   Andreas: I agree with Cyril, at least with the option, to just
   allow in the syntax what is in the data model.
   … I'm not sure how much work it would be to make this, because
   maybe several parts of the spec are affected.
   … It makes the implementation easier.
   … This is something people complain about with TTML, with some
   of the existing profiles.
   … That would be the strongest solution maybe.
   … Another would be a weaker recommendation to use it like the
   data model says.

   Nigel: Couple of points.
   … First I think we should explicitly state that the diagram is
   informative, in case there's an unintended
   … clash between the diagram and the text.
   … Second, I am wary of making implementations more complex
   rather than less complex by introducing more
   … conditions on what is permitted on specific elements. For
   example, it's easy to implement generic
   … xml:lang inheritance when it can be set on every element in
   the tree, but if you restrict to only certain
   … element types then that adds implementation complexity.
   … I think we need to tread the line carefully.
   … There definitely are cases where we would want specific
   restrictions.
   … Options I've heard so far (maybe not mutually exclusive):
   … 1. Add additional restrictions via extension features
   … 2. Make data model diagram informative
   … 3. Recommend only making TTML2 documents that match the data
   model
   … any others?

   Cyril: I think we should do some sort of analysis of the
   possible differences.
   … An alternative would be to say not that we put restrictions
   in the syntax, but indicate processing
   … behaviours when encountering syntax that does not adhere to
   the data model, but that is TTML acceptable,
   … maybe recommend that processors may or should ignore it, to
   allow a simplified implementation.
   … One example: today we say a script is made of a list of
   script events where each is a div with a specific syntax.
   … What if you encounter an extra div that is used for some
   other purpose and does not match the requirements of a Script
   Event?
   … I think processor-recommended behaviour might be a good
   option.

   Andreas: That's what I think Nigel meant by making things more
   complex.
   … For example different processor behaviour for DAPT processors
   than generic TTML processors may be a problem.
   … With xml:lang, if you ignore it on body or div then it may
   not work, and that would add complexity.

   Cyril: I understand that, I think we all agree we don't want
   that behaviour.
   … Maybe there are cases where this could be applicable.

   Nigel: My other suggestion is to clarify that the TTML2 feature
   support required by the specification defines
   … the processor behaviour, even if there's a difference from
   the data model.
   … In the example that Cyril gave before of a non-Script Event
   div, if an implementation doesn't know what to do
   … with it I think I'm not that unhappy with it being an
   implementation behaviour, for example in an authoring tool.

   Andreas: I think a clear guideline is needed for implementers.
   … I agree with Cyril's proposal to do some analysis.
   … If we say that TTML2 governs if there are differences it
   could lead to a sense of lack of clarity or uncertainty,
   … and make people look more deeply into TTML2 to get these
   cases.

   Cyril: I wonder if we should add to the "is represented by"
   some statement about processing behaviour
   … if other elements or attributes are encountered then the
   extensibility clause applies, or whatever.
   … I wonder if a way to be exhaustive would be to do that
   systematically for every section, to make sure we don't
   … miss anything.

   Nigel: I think it's best to do this before CR, but I think
   doing this puts the 2 week suggestion under threat!

   Cyril: I get that - this one is a true CR must have I would
   say.

   Pierre: When was the last draft published?

   Nigel: 15th February

   Cyril: We publish on every pull request merge
   … I propose to open a new issue to try and address this,
   identifying potential gaps between syntax capabilities
   … and the model.
   … That's an action for me.
   … Are we okay to merge the pull request?

   Nigel: I've approved this, I think we're fine unless anyone
   objects.

   Cyril: I can open the issue and merge the pull request with a
   note that further discussion will continue on the issue.

   Nigel: Sounds good to me.

   Cyril: On the xml:lang, would there be any objection to
   allowing Language on the Script Event?

   Nigel: I think it's premature

   Pierre: I've lived through that painfully in IMSC. Is it
   limited today?

   Cyril: in XML syntax no, but in data model yes.

   Pierre: My experience with IMSC: I'd treat the two completely
   separately.
   … The xml:lang in XML has a specific set of rules for
   inheritance. I would not try to restrict that at all.
   … Just follow the inheritance rules in the XML, where every
   element in the hierarchy has a computed value
   … of xml:lang, and then when you map that back to the model you
   use the computed value.
   … Trying to limit it in XML is super hard. Just let it be and
   use the computed value to infer the values in the model.

   Nigel: I think you've pointed the way forward there.

   Pierre: Let's say the data model says there's no Language on an
   element , you just ignore it on things where it's not in the
   data model.

   Nigel: I think that's it - stuff can be in the syntax but only
   has significance on objects in the data model.

   Pierre: I think that's the idea in TTML - applies to xml:space
   and everything else really.

   Nigel: Thanks we're out of time on this but that's a good point
   to end this discussion.

  DST changes

   Pierre: my input is 7am Pacific and 10am Pacific are impossible
   for me, but 8am and 9am are fine.

   Nigel: We're out of time today so will have to move this
   offline.

   Cyril: Same for me as Pierre - 7am Pacific is a stretch but 8am
   or 9am works.

   Nigel: I'll have to do the mapping to understand what that
   means in practice
   … I think in previous years we have tracked America on this
   change because it's not so onerous in Europe.

   Atsushi: I wondered which direction things would go here.

   Nigel: You've got i18n too, which must have the same problem.

   Atsushi: Usually i18n sticks to UK.

   Nigel: You could end up with a clash I think.

  Meeting close

   Nigel: Thanks everyone, apologies that we've run over today.
   [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