Description
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).
Activity
[-]Single-level overrides (more fun with `additionalProperties`/`additionalItems`[/-][+]Single-level overrides (more fun with `additionalProperties`/`additionalItems`)[/+]epoberezkin commentedon May 22, 2017
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 commentedon Aug 20, 2017
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.
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:
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 commentedon Aug 21, 2017
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 commentedon Aug 21, 2017
@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 commentedon Sep 1, 2017
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 commentedon Nov 28, 2017
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.