-
-
Notifications
You must be signed in to change notification settings - Fork 292
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
default
should probably be required to validate
#125
Comments
As I described in #123, MUST... or else what? MUST proscribes behavior for implementations. See https://tools.ietf.org/html/rfc2119 which was written to address these kinds of questions, particularly section 6. |
@awwright thanks for pointing to that for clarity. Yeah, I was thinking MUST. I guess the part that remains a little unclear to me would be the scoping of this. It seems like there are two possible readings (and perhaps you can clear up for me which is more accurate). Something like:
I was thinking about it like 2, but it sounds like you may be thinking about it more like 1? If not that, it sounds like this may still push some burden toward the implementors as they might be required to validate this value? That wasn't really my intention, so much as making the spec more clearly reflect what I understand to be the intention. Does that help/clarify? |
I think this is the main concern, and having read @awwright's explanation and refreshed my memory of the RFC he linked, I tend to agree. RECOMMENDED (and SHOULD) mean that:
This sounds like the right level of caution for anyone deciding to go against the recommendation. I had previously thought that RECOMMENDED meant something less emphatic, but this seems good to me. |
Yeah, sounds reasonable once we dug into specifics. Will close now, thanks for discussing. |
In #123 it came up that
default
isRECOMMENDED
as valid, but it seems as though a non-valid value here would actually not function as a default. As such, it seems as though we may want to harden the language here toMUST
in order to protect defaults from resulting in invalid data.The
RECOMMENDED
language in question is here: https://github.com/json-schema-org/json-schema-spec/blob/master/jsonschema-validation.xml#L622P.S. Should #123 be accepted, to add the
example
keyword, it should probably also get this change to stricter language, for the same reasons.The text was updated successfully, but these errors were encountered: