Single-level overrides (more fun with `additionalProperties`/`additionalItems`)

[handrews]

In an effort to get all options on the table for the next batch of work, yet another solution to the re-use with additionalProperties conundrum would be a simple single-level override of keywords.

This could either support all schema keywords, in which case it is a simpler version of #15 ($merge/$patch), or a limited subset of keywords such as non-validation keywords, in which case it is a simpler version of #98 ($use). It could use the $use syntax (assuming we would not implement both this and #98), or (as discussed in #98) it could just be handled by defining the behavior of other keywords alongside of $ref. In any approach, it avoids the nightmarish complexity of #119 ($combine).

A single-level override avoids having to make any choices about complex merge behavior, in particular that proposed for $combine. If keyword X is overridden, the entire old overridden value of X, including all subschemas, is disregarded in favor of the new overriding value.

While the reliance of standard media types means that $merge and $patch are easy to implement in practice, the possibilities of arbitrary editing makes it hard to reason about the results. Single-level overrides reduce those possibilities and make the effects more intuitive.

Finally, single-level overrides avoid the major complexity involved in the $use proposal, which is the need to filter out forbidden keywords at arbitrary depths from the with clause. If only a single level override is allowed, with no merging or other sort of deep editing, it is easy to check which keywords are being overridden at that single level and ensure that they meet any restrictions (e.g. that they are not validation keywords).

[epoberezkin]

Syntax for this idea could be similar to #321: $override as extension to $ref and $override on the schema level to allow/prohibit overriding certain keywords (or any keywords).

[handrews]

VOTE-A-RAMA!!!

It's time to gauge community support for all re-use/extension/additionalProperties proposals and actually make some decisions for the next draft.

Please use emoji reactions ON THIS COMMENT to indicate your support.

• You do not need to vote on every proposal
• If you have no opinion, don't vote- that is also useful data
• If you've already commented on this issue, please still vote so we know your current thoughts
• Not all proposals solve exactly the same problem, so we may end up implementing more than one

This is not a binding majority-rule vote, but it will be a very significant input into discussions.

Here are the meanings for the emojis:

• Celebration: I support this so strongly that I want to be the primary advocate for it
• Heart: I think this is an ideal solution
• Smiley face: I'd be happy with this solution
• Thumbs up: I'd tolerate this solution
• Thumbs down: I'd rather we not do this, but it wouldn't be the end of the world
• Frowny face: I'd be actively unhappy, and may even consider other technologies instead

If you want to explain in more detail, feel free to add another comment, but please also vote on this comment.

The vote should stay open for several weeks- I'll update this comment with specifics once we see how much feedback we are getting and whether any really obvious patterns emerge.

[erayd]

My approval for this proposal is contingent on it being a general-purpose override that supports all schema keywords. If it were limited to e.g. non-validation keywords only, then it only solves half the problem. The limitation to specific keywords is my primary objection to $use.

$merge / $patch feels nicer / more complete, but a general-purpose single-level override would address every current use-case I have for this kind of thing; I don't personally need multi-level in anything at present (although I may want it in the future).

[handrews]

@erayd could you please comment on #15 and give your use cases that aren't addressed by $use? That is the kind of thing that will help decide between those two (if voting follows the recent status quo, $use has more support).

If we do this proposal, we'll decide whether it is based on $merge/$patch or $use based on how we decide between those actual proposals (if we don't do either, we'll still look at the relative vote strength to help decide here).

[handrews]

Note that the extensibility mechanism proposed in #388 could be used to indicate this option as well, although I would strongly prefer to minimize the number of recommended extensions in draft-07.

[handrews]

At the end of the vote-a-rama, I said that I would consolidate these issues to focus the discussion for draft-08. I've filed #515 which outlines the two possible competing approaches. It's pretty abstract, but once we choose an approach, deciding which exact keyword and behavior we want should be less controversial. Therefore I'm closing this in favor of #515.