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

"may be considered" #131

Closed
ghost opened this issue Nov 5, 2016 · 2 comments
Closed

"may be considered" #131

ghost opened this issue Nov 5, 2016 · 2 comments

Comments

@ghost
Copy link

ghost commented Nov 5, 2016

I apologize if this is the wrong place to ask this question.

A colleague of mine and I have come to a disagreement about this verbiage, "may be considered." What does the expression "may be considered" mean in these contexts in the JSON Schema Validation specification?

  • "minLength", if absent, may be considered as being present with integer value 0.
  • If ["minItems"] is not present, it may be considered present with a value of 0.
  • If not present, ["uniqueItems"] may be considered present with boolean value false.
  • If this keyword is not present, ["minProperties"] may be considered present with a value of 0.
  • If "additionalProperties" is absent, it may be considered present with an empty schema as a value.

Given that these values are the assigned defaults for these properties in the online version of the JSON schema JSON, I took "may be considered" to mean that these values should be used if their respective properties are not present. My colleague disagrees and says that "may be considered" indicates that these are just suggested values and that other default values may be used instead.

The particular instance we disagreed about was "additionalProperties." He insists on setting the default value to false, saying that "may be considered" means that he does not have to interpret a missing "additionalProperties" to be an empty schema. I insist that the value should be set to an empty schema when the property is not present.

Were these values which may be considered just suggestions with intentional allowance for alternate default values, or are they to be considered recommended default values?

@awwright
Copy link
Member

awwright commented Nov 5, 2016

@joe-chung Are you writing an implementation, or a schema?

"may be considered" here is non-normatively describing which values have the same behavior as a missing keyword.

We should probably choose a better way to express this, but it's pretty much just included as an example for implementors to verify they understand the behavior correctly.

Another way to say this, is that all the following schemas should exhibit the same behavior:

{}
{minLength: 0}
{minItems: 0}
{uniqueItems: false}
{minProperties: 0}
{items: []}
{properties: {}}
{additionalProperties: {}}
{additionalItems: {}}

etc. These all will always validate successfully, for any instance.

I guess you can think about them as default values, but strictly speaking they're just different values that exhibit the same behavior (never fails to validate).

The "default" keyword in the meta-schema is expressing this, it's just supplying a value that's a sensible default for an editor to initially display if you were authoring a new JSON document from scratch -- ideally, a value that has the same behavior as a missing value.

For validating an instance, remember a validation only fails if one of the keywords fails. Validation will never fail if there's no keywords.

Along this line, if you're producing a schema, I wouldn't include any keywords that would never fail validation. So, I prefer {} over {additionalProperties: {}}. There might be a good reason to do it a different way.

Please let me know if this clarifies things, and if you have any suggestions to improve that language.

@ghost
Copy link
Author

ghost commented Nov 6, 2016

Thank you for your response. The question is for an implementation which consumes schema. Your clarification was quite helpful. I was fine with the language, but I will consult with my colleague if he has any suggestions to improve the language.

This issue was closed.
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

1 participant