Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

additionalProperties - don't allow booleans as value, emulate 'true' behaviour using anyOf or $ref #133

Closed
jschnaitmann opened this issue Nov 7, 2016 · 3 comments
Labels
clarification Items that need to be clarified in the specification

Comments

@jschnaitmann
Copy link

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?):

additionalProperties: {
    "$ref": "#/definitions/simpleTypes"
}

This would also disallow additionalProperties by default.

@handrews
Copy link
Contributor

handrews commented Nov 7, 2016

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.

@awwright
Copy link
Member

@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?

@handrews
Copy link
Contributor

handrews commented Jan 5, 2017

@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.

@handrews handrews closed this as completed Jan 5, 2017
@gregsdennis gregsdennis added clarification Items that need to be clarified in the specification and removed feedback labels Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Items that need to be clarified in the specification
Projects
None yet
Development

No branches or pull requests

4 participants