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

default should probably be required to validate #125

Closed
geemus opened this issue Nov 3, 2016 · 4 comments
Closed

default should probably be required to validate #125

geemus opened this issue Nov 3, 2016 · 4 comments

Comments

@geemus
Copy link
Collaborator

geemus commented Nov 3, 2016

In #123 it came up that default is RECOMMENDED 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 to MUST 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#L622

P.S. Should #123 be accepted, to add the example keyword, it should probably also get this change to stricter language, for the same reasons.

@awwright
Copy link
Member

awwright commented Nov 4, 2016

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.

@geemus
Copy link
Collaborator Author

geemus commented Nov 4, 2016

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

  1. You MUST have a default, and it MUST be valid.
  2. You MAY have a default, and if you do, it MUST be valid.

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?

@handrews
Copy link
Contributor

handrews commented Nov 4, 2016

it sounds like this may still push some burden toward the implementors as they might be required to validate this value?

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:

there may exist valid reasons in particular circumstances to ignore
a particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

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.

@geemus
Copy link
Collaborator Author

geemus commented Nov 7, 2016

Yeah, sounds reasonable once we dug into specifics. Will close now, thanks for discussing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants