Fix missing "if present" for "else" #554
Conversation
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
Outdated
| @@ -799,8 +801,9 @@ | |||
| <t> | |||
| 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 | |||
There was a problem hiding this comment.
I know this isn't your change, but I find the phrasing...
"When "if" is absent, or the instance successfully validates against its subschema, validation against this keyword always succeeds..."
This reads to me as, when the subschema of if successfully validates, else always succeeds [validation], regardless of the actual validation result of the instance against it's subschema.
That can't be the intent...
There was a problem hiding this comment.
Great feedback, I'll play around with this some more.
The main point of bug-fixing the validation spec is to clarify if/then/else so please highlight everything that's awkward.
jsonschema-validation.xml
Outdated
| @@ -780,8 +781,9 @@ | |||
| <t> | |||
| 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 | |||
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.
|
Rewrote "if" etc. to be more explicit about how the keywords In particular, an "if" on its own collects annotations but Technically, "then" could be assigned an empty schema default If "if" has a default of true/empty schema, then "then" on Note that the meta-schema always puts in a default, but this was |
| 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 |
| 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. |
There was a problem hiding this comment.
/evaluated/are applicable/ ? Thinking we should use applicability termonology where possible.
gregsdennis
added
clarification
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.