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
Nigel: To do that, I created a privacy and security self review
Pull Request to add Privacy and Security self-questionnaire
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]