Open Community (TDC) Meeting, Thursday 16 May 2024 about openapi-specification

[handrews]

• If anyone is on the call who knows the 2.0 / 3.0 referencing intent, let's talk about #3772 (but if not, I'll update it based on feedback so far and take it out of draft as it has enough approvals, so no need to spend time on that in the call)
• Competing alternative solutions for #3792 (seriously, what is going on here- apparently the default value prevents poorly-defined "empty" values, but we've deprecated the non-default value? Do we just not support empty parameters? What is the justification for that?)
  • #3798
  • #3803
• We should look at these schema-related PRs from new contributor @TakahikoKawasaki
  • #3790
  • #3791
• #3808 (Can anyone confirm the timeline of Jason Harmon's TSC tenure?)
• #3740 (our allegedly normative Markdown doesn't include the references list (can we just deem the rendered HTML authoritative now since it is literally the only complete presentation of the spec?) and splitting normative and informative references turns out to be more complex than first seems, as @Bellangelo discovered by trying to submit a PR)
• More issues for review – How many TSC opinions are necessary to take an issue out of review and work on a PR and not risk the PR being shot down by other TSCers? (of course, sometimes PRs get shot down anyway, but in general...?)
  • #1551 (comment) (more obscure form serialization problems)
  • #3800 (comment) (should we update RFC numbers in patch releases or only in minor releases? ignore my ranting about whatwg, that was a tangent)
  • OAI/sig-moonwalk#112 (@ralfhandl has suggested lumping this in with the Moonwalk reconsideration of the whole area, does that work for everyone? If so I'll label it Moved to Moonwalk and close)
  • #1806 (comment) (is there anything here we're going to do, or should we just close this?)
  • #1435 (comment) (is anyone willing to look at XML bug reports? If not, should we delcare that we're not supporting XML anymore and close them all? This is one of the most obvious problems so I figured it was a decent starting point)

[lornajane]

We did not cover a lot of ground this week, but we had some really good discussions on deeply technical topics.

• #3772 hinges on the intention (which isn't clearly written) of whether references are supposed to be context-dependent or not. In 2.0, references inlined the target content. In 3.1, the reference behaviour is clearer - but in 3.0, it's not clear. This matters because while we don't want to spend a lot of time on small (but impactful!) details of 3.0, a compliance tool is being created for 3.0 and these details are important.
• #3798 discussion concluded with the idea that if the field was called disregardEmptyValues, it would make more sense. The idea is that while in its default state (allowEmptyValues is false) an empty value is an empty value and should be handled as empty, when allowEmptyValues is true then the empty value should be ignored by the server. The use case is browsers sending all fields where some of them are empty.
• #3790 is a contribution aimed at helping us move forward with the schemas. However it's written in Ruby which isn't currently a tech stack used in the project. We've asked if it can be changed since adding more and more technical dependencies and requirements to the project doesn't help people to get started or participate.
• We did merge #3808 after checking the details of past maintainers
• We discussed the merits of adding defaults to parameters (currently this is only on schemas) OAI/sig-moonwalk#112 . It's not clear how this should look and since we don't have support in 3.x yet, this issue has been moved to Moonwalk to consider. When that spec takes shape, we'll be evaluating which of those solutions can be adopted by minor or patch updates in the 3.x branch.