You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would make the definition, in my opinion, more readable and robust if the additionalProperty attribute would only allow object values.
The former additionalProperties = false would be represented by the default empty object value {}. The former additionalProperties = true could be achieved with something like this (or possibly using anyOf?):
We're actually going in the other direction of allowing true and false for subschemas everywhere (see #101 and #128 )
Also, true is equivalent to {} while false is equivalent to the much more awkward {"not": {}}. Using the booleans is both more clear to read (for many of us) and makes the intent very clear.
@jschnaitmann additionalProperties true is the same as {}. And I'm not sure what's being done with $ref here, what is the definition you're referring to here?
@jschnaitmann Since this was filed we've made true and false valid schemas everywhere, with clearly defined behavior (in terms of the canonical translation to object schemas). This means that "additionalProperties" is no longer an exception.
Since you didn't reply to that when I first mentioned it two months ago, I am assuming that you've dropped this. Please re-open if you have new arguments for this proposal.
It would make the definition, in my opinion, more readable and robust if the additionalProperty attribute would only allow object values.
The former additionalProperties = false would be represented by the default empty object value {}. The former additionalProperties = true could be achieved with something like this (or possibly using anyOf?):
This would also disallow additionalProperties by default.
The text was updated successfully, but these errors were encountered: