From d924055233881db78d7acf0877a32257923d28c0 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Wed, 28 Feb 2018 09:51:35 -0800 Subject: [PATCH 1/2] Fix missing "if present" for "else" Also other minor wording clarifications for if/then/else such as standardizing the "regardless of the validation outcome against the subschema" language. That language is important as it clarifies that subschema validation can fail (causing annotations to be dropped) without causing the containing schema to fail. --- jsonschema-validation.xml | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 46d4b24c..6207e1a7 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -759,12 +759,13 @@ Instances that fail to validate against this keyword's subschema MUST also be valid against - the subschema value of the "else" keyword. + the subschema value of the "else" keyword, if + present. Validation of the instance against this keyword on its own always succeeds, regardless of the - validation outcome of against its subschema. + validation outcome of the instance against its subschema.
@@ -780,8 +781,9 @@ When "if" is absent, or the instance fails to validate against its subschema, validation against - this keyword always succeeds. Implementations - SHOULD avoid attempting to validate against + this keyword always succeeds, regardless of the + validation outcome of the instance against its subschema. + Implementations SHOULD avoid attempting to validate against the subschema in these cases.
@@ -799,8 +801,9 @@ When "if" is absent, or the instance successfully validates against its subschema, validation against - this keyword always succeeds. Implementations - SHOULD avoid attempting to validate against + this keyword always succeeds, regardless of the + validation outcome of the instance against its subschema. + Implementations SHOULD avoid attempting to validate against the subschema in these cases. From 0bc8cdeb4e7faa8e2f94b80abf4f62d36f667695 Mon Sep 17 00:00:00 2001 From: Henry Andrews Date: Tue, 13 Mar 2018 10:53:59 -0700 Subject: [PATCH 2/2] More thorough rewrite of "if"/"then"/"else" Further feedback indicates the language was still confusing. Rewrote it to be more explicit about how the keywords interact with each other and with both validation and annotation collection. In particular, an "if" on its own collects annotations but never affects validation, annotations are only collected from "them" or "else" if their use is indicated by the validation outcome of an adjacent "if", and there is no default behavior for any of the keywords. Technically, "then" could be assigned an empty schema default without causing problems, but that felt weirdly unbalanced. If "if" has a default of true/empty schema, then "then" on its own would be active, which is counter-intuitive. If "else" had a default it would need to be false rather than true, and saying it has no default seemed simpler, and matches how "not" is handled. "not" is the only other keyword that would otherwise need a false schema as a default value. --- jsonschema-validation.xml | 59 +++++++++++++++++++++++---------------- 1 file changed, 35 insertions(+), 24 deletions(-) diff --git a/jsonschema-validation.xml b/jsonschema-validation.xml index 6207e1a7..70dce2a3 100644 --- a/jsonschema-validation.xml +++ b/jsonschema-validation.xml @@ -746,10 +746,23 @@ branch of an "allOf" MUST NOT have an impact on a "then" or "else" in another branch. + + There is no default behavior for any of these keywords + when they are not present. In particular, they MUST NOT + be treated as if present with an empty schema, and when + "if" is not present, both "then" and "else" MUST be + entirely ignored. +
This keyword's value MUST be a valid JSON Schema. + + This validation outcome of this keyword's subschema + has no direct effect on the overall validation + result. Rather, it controls which of the "then" + or "else" keywords are evaluated. + Instances that successfully validate against this keyword's subschema MUST also be valid against @@ -763,9 +776,10 @@ present. - Validation of the instance against this keyword - on its own always succeeds, regardless of the - validation outcome of the instance against its subschema. + If annotations + are being collected, they are collected from this + keyword's subschema in the usual way, including when + the keyword is present without either "then" or "else".
@@ -773,18 +787,17 @@ This keyword's value MUST be a valid JSON Schema. - When present alongside of "if", the instance - successfully validates against this keyword if - it validates against both the "if"'s subschema - and this keyword's subschema. + When "if" is present, and the instance successfully + validates against its subschema, then valiation + succeeds against this keyword if the instance also + successfully validates against this keyword's subschema. - When "if" is absent, or the instance fails to - validate against its subschema, validation against - this keyword always succeeds, regardless of the - validation outcome of the instance against its subschema. - Implementations SHOULD avoid attempting to validate against - the subschema in these cases. + This keyword has no effect when "if" is absent, or + when the instance fails to validate against its + subschema. Implementations MUST NOT evaluate + the instance against this keyword, for either validation + or annotation collection purposes, in such cases.
@@ -792,19 +805,17 @@ This keyword's value MUST be a valid JSON Schema. - When present alongside of "if", the instance - successfully validates against this keyword if - it fails to validate against the "if"'s - subschema, and successfully validates against - this keyword's subschema. + When "if" is present, and the instance fails to + validate against its subschema, then valiation + succeeds against this keyword if the instance + successfully validates against this keyword's subschema. - When "if" is absent, or the instance successfully - validates against its subschema, validation against - this keyword always succeeds, regardless of the - validation outcome of the instance against its subschema. - Implementations SHOULD avoid attempting to validate against - the subschema in these cases. + This keyword has no effect when "if" is absent, or + when the instance successfully validates against its + subschema. Implementations MUST NOT evaluate + the instance against this keyword, for either validation + or annotation collection purposes, in such cases.