Should we add test cases asserting the validity of "controversial" or "questionable" practices?

[duncanbeevers]

🗣️ Discussion

Some PRs proposing changes to the validation schema enforce constraints not specified in the OpenAPI specification. Such changes are considered linty.

Such changes are typically dismissed after maintainer review.
Some discussion end in "well, it's allowed by the spec".
This discussion is intended to shorten the feedback loop between proposal-which-will-not-be-accepted to proposal-which-may-be-accepted.

Instead of rejecting such PRs out-of-hand, I propose we instead open counter-PRs which add test cases explicitly asserting the validity of such controversial cases.
This will help to steer future contributors away from anti-patterns which are not explicitly disallowed by the specification, and provide specific points of adjustment should the specification change with regards to these anti-pattern test cases.

This PR seeks to add tests which assert certain anti-patterns are explicitly allowable, despite their incongruousness or meaninglessness.
The intention is not to lock the schema into these behaviors, but to guide contributors towards areas where their updates make sense (custom linters, etc…) rather than rejecting contributor PRs on first principles.

[handrews]

My main concern here is the effort vs value trade-off of doing this work. If a volunteer wants to do this and can do it without taking up a lot of the time of people who would otherwise be working on the spec, then that's great. But if it's going to take a lot of back and forth about minutia like the "'#'-in-path-templates" question did, I'm against it (as the person who is most likely to get asked about minutia, especially involving URIs).

[duncanbeevers]

Reasonable…
I'm not proposing a mandatory response, but rather a general strategy of addressing incoming changes in a way that both handles the immediate case and refines the suite to assert more of the positive and anti-positive cases actually encountered in The Wilds. (The Wilds, in this case being the PRs opened against the spec repo).

[duncanbeevers]

As much as I too dislike back-and-forth on minutia, going through the process and codifying the outcome still seems superior to the alternatives:

1. Having the discussion again without context (the participants have forgotten, or are a different set)
2. Short-circuiting the discussion by referencing the previous discussion (some participants remember and spend time digging up receipts)
3. Squashing the discussion (some participants remember, and squash discussion without receipts)

In this fragments-in-paths-keys case, it's not clear whether there's a distinction between tricky subjects and minutia subjects, but I feel much of the organization's value comes in exploring and ironing-out tricky questions, and codifying those results to the best of our abilities, either in the spec itself, or in the schemas supporting the spec.

[ralfhandl]

Examples for questionable practices risk becoming copy templates, even if they are clearly marked as "don't do this".