{Minutes} TTWG Teleconference 2022-11-24

Thanks all for attending today’s TTWG call (even if it’s a public holiday for you!). Minutes can be found in HTML format at https://www.w3.org/2022/11/24-tt-minutes.html


In text format:

   [1]W3C

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


                Timed Text Working Group Teleconference

24 November 2022

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

      [2] https://www.w3.org/2022/11/10-tt-minutes.html

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

      [4] https://www.w3.org/2022/11/24-tt-irc


Attendees

   Present
          Amy, Amy_(rhiaro), Andreas, Chris_Needham, Cyril, Gary,
          Nigel, Pierre, rhiaro, Xabier

   Regrets
          none

   Chair
          Gary, Nigel

   Scribe
          cpn, nigel

Contents

    1. [5]This meeting
    2. [6]Rechartering Formal Objection Council status update
    3. [7]DAPT
    4. [8]IMSC HRM
    5. [9]Meeting Close

Meeting minutes

  This meeting

   Nigel: For the agenda today we have:
   … Rechartering Formal Objection Council status update
   … DAPT, IMSC-HRM
   … Any other business to raise?

   group: [no other business]

  Rechartering Formal Objection Council status update

   Nigel: We have received the FO Council members, and an email
   from the chair

   Amy: The Council met on Monday 21st this week.
   … Apologies again for how long this took.
   … The outcome in short is that the Council has done what should
   … arguably have been done to prevent the Council in the first
   place,
   … where they've drafted some alternate text.
   … This is different from previous Councils that have upheld (or
   not) the Objections.
   … In the past the Director always sought consensus between the
   parties.
   … In that spirit we have this outcome, that might seem
   unexpected.
   … If you have any more questions about the process, I can do my
   best to answer them.
   … I chaired it but I'm not an expert in the process itself.
   … I sent a draft of a few edits to the Success Criteria §3.1 of
   the Charter,
   … which was discussed at length.
   … The draft was written by me and Florian after the meeting and
   circulated
   … to check it represents consensus in the meeting, which it
   did.
   … I want to check if it matches the intention of the TTWG.
   … There was some ambiguity about testing individual features vs
   whole specifications.
   … I'm not sure if you've had time to read the proposal yet.
   … I feel there is not a substantive conflict of intent, it
   feels like a matter of interpretation.
   … Happy to answer questions.

   Nigel: Thank you. The theme you put forward is whether the
   language is clear to explain our thinking, that's good feedback
   … At the same time, having been involved in the discussions, it
   felt like we said what we meant, and the proposal does change
   things to some extent
   … I'm not sure we're in a position to go into the detail, need
   time to review the proposal
   … I see three insertions in the edit: to clarify that the two
   independent factors of verification are for each normative
   requirement
   … want to understand what that does
   … And the two factors are the ones relevant for the requirement
   … And on content, added "producing implementation", meaning
   some form of authoring tool
   … [reads the proposed text]
   … My question is what is the difference between "normative
   feature" and "normative requirement"?

   Amy: My reading is that requirements are synonymous with
   features. It's intended to mean the normative requirements that
   the spec imposes on implementations
   … It was in the interest of removing any ambiguity.

   Pierre: Going back to the team report provided to the council,
   did the council review it?

   Amy: We were all asked to review it, I did several times

   Pierre: There's a paragraph on how the WG plans on using the
   flexibility in the charter and exit criteria. Does the proposed
   text allow us to do this?
   … The team report had a specific example of how the exit
   criteria could be met

   Amy: Our intent is that it would meet the needs of the WG

   Pierre: Does the FO council feel the plan we laid out would
   satisfy the wording proposed by the council?

   Amy: It's outside my domain, so hard to get up to speed on what
   it's for. My question to the WG is does it meet the needs, and
   can explore further if not - we need to answer this question
   together.

   Pierre: The WG plan in this particular case, is to demonstrate
   implementation experience through the open source validator
   … Combine an OSS validator implementation with test content
   produced by independent parties with their own authoring tools
   … The plan was to use the independence of the validator and the
   content authors, to show implementation experience
   … Does that satisfy the FO council criteria?

   Amy: This where really understanding the spec in question would
   be helpful. Is the spec for a consuming implementation?
   … I have experience with data models, where you validate with a
   test suite
   … I haven't seen a situation where one set of content with a
   validator counts
   … The content could be written to the validator implementation
   not the spec
   … But I don't know if that applies in this case
   … Does it specify content or validator requirements, or both?

   Pierre: The validator assumes as input a syntactically valid
   document
   … The validator applies a set of criteria intended to mimic how
   an implementation scales, to see if the document would be too
   complex for an implementation to render
   … The output indicates if the document is too complex, yes or
   no
   … Allows the document complexity to be constrained, and also
   affects designers of presentation engines, as they want to
   present correctly everything that passes the validator
   … The intent of the complexity model that results in the
   validator is to maximise the chances that documents produced by
   one party can be consumed by a presentation engine produced by
   another party
   … A couple of things we're trying to demonstrate: correctness
   of the spec, and confirm that the constraints in the spec meet
   community needs
   … So we have multiple goals for implementation experience
   … Something different to other specs, it's unlikely for a
   community standpoint that there's a need for multiple
   validators in practice
   … Community resources are limited, so the sense is it's better
   to spend effort testing the validator with real content, rather
   than create a second or more validator implementations

   Nigel: (sorry to interrupt) but we also have synthetic tests -
   the idea is not to test solely on real world content.

   Pierre: Yes. If other validators were presented, we'd accept
   them. But to focus resources on demonstrating interoperability,
   use the single OSS implementation and use actual content from
   different entities

   Amy: Thanks for the explanation, I'm trying to understand this
   … Does the spec put requirements on content or the validator,
   or a mix?

   Pierre: It's a mix of both

   Amy: On passing content from multiple providers, that seems
   fine and meets the requirement
   … I wonder if there's a way of framing it in the spec that the
   requirements placed on the validator can be placed on content.
   Would that make sense?

   Pierre: Whether content or authoring or validation profile,
   it's all related
   … Passing one requirement implies passing the other
   … [example of requirement for painting a region]
   … They're inseparable, one can be recast into the other

   Amy: Framing it as normative on content, and passing multiple
   content through, seems strong

   Pierre: I want to check if you feel that text recommended by
   the council would allow the exit criteria

   Amy: I can't speak for the whole council, but it seems ok to me

   Pierre: Would it help to describe in more detail?

   Amy: It would be helpful for the WG to discuss the proposed
   text, see if it meets your needs.
   … Can go into more detail if there are questions

   Pierre: If it's felt it meets charter requirements, we want to
   avoid having a subsequent objection when we get to PR

   Nigel: Thank you both. I want to return to there being some
   ambiguity about why we're talking about features rather than
   whole specifications
   … The current Process allows specifications have feature
   additions once reached Rec status

   <Zakim> nigel, you wanted to mention why the success criteria
   are defined in terms of feature

   Nigel: I also wanted to check, what's the intent of "as
   relevant for that requirement"? How would someone assess which
   kinds of implementation are relevant for a particular
   requirement? Does the council have a test in mind?

   Amy: On defining in terms of features, that's the right way to
   do it
   … If there are requirements on content, we'd want to see two
   pieces of content from different implementers
   … If there's a requirement on validators, members of the AC
   would expect to see two validators to meet the requirement
   … That's why it could make sense to reframe as requirements on
   content

   Nigel: It makes sense that we state the CR Exit Criteria in the
   CR, as we usually do, so we would assess relevancy.

   Nigel: The action is on us to think carefully and come back
   with an answer
   … May not be able to do that until our next call

   Amy: That's fine. I'll do my best to turn this round as quickly
   as possible
   … If the alternative is the council upholds the objection and
   returns it to the WG, you'd have to go through the AC again. So
   hoping to have a faster way to resolve it than that

   Pierre: How does the council know this would satisfy the
   objector?

   Amy: There are two Apple representatives on the council, and
   they've said as much

   Pierre: Thank you for trying to get consensus. We've had
   repeated attempts, trying to get a discussion on a compromise

   Amy: That was on the council agenda

  DAPT

   Nigel: Cyril and I did a review, we plan to have regular
   editors calls between group meetings
   … We have work to do, but no issues needing WG input. We closed
   some of Andreas's issues, considering them done.
   … Please reopen them if you don't agree.

   Cyril: We're working on the spec to address editorial comments,
   then come back to the group for input
   … Andreas, suggest waiting a bit, then do a review of the whole
   thing, once it's become stable

   Andreas: Just let me know when it's ready, thank you

  IMSC HRM

   Nigel: I initiated TAG review

   [10]TAG review issue

     [10] https://github.com/w3ctag/design-reviews/issues/788


   Nigel: To do that, I created a privacy and security self review

   [11]Pull Request to add Privacy and Security self-questionnaire

     [11] https://github.com/w3c/imsc-hrm/pull/57


   Nigel: The answers I think are uncontroversial
   … Pierre and Gary, please review
   … Once reviewed I can update the TAG review issue to point to
   the markdown document rather than the PR

   Pierre: I'll do that
   … Thought we'd done this already?

   Nigel: Atsushi commented that there weren't security
   implications, but that's not the same as filling in the self
   review

   Pierre: PING reviewed it already, and closed it earlier this
   year
   … It's linked from issue 19

   Pierre: There was also a security review filed last December,
   but not closed

   Nigel: The TAG wants to see the self review questionnaire. Can
   link to the issues so they know it's happened
   … I can check what happened with the security review

   Nigel: We're out of time, we had other issues to discuss

   Pierre: Let's follow up offline

  Meeting Close

   Nigel: Thanks everyone

   [adjourned]


    Minutes manually created (not a transcript), formatted by
    [12]scribe.perl version 196 (Thu Oct 27 17:06:44 2022 UTC).

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