Skip to content

Fix missing "if present" for "else" #554

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.

Sign up for GitHub

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

Merged
merged 2 commits into from
Mar 14, 2018
Merged

Fix missing "if present" for "else" #554

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d924055
Fix missing "if present" for "else"
handrews Feb 28, 2018
0bc8cde
More thorough rewrite of "if"/"then"/"else"
handrews Mar 13, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 37 additions & 23 deletions jsonschema-validation.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -746,10 +746,23 @@
branch of an "allOf" MUST NOT have an impact on a "then"
or "else" in another branch.
</t>
<t>
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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

entirely ignored.
</t>
<section title="if">
<t>
This keyword's value MUST be a valid JSON Schema.
</t>
<t>
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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/evaluated/are applicable/ ? Thinking we should use applicability termonology where possible.

</t>
<t>
Instances that successfully validate against this
keyword's subschema MUST also be valid against
Expand All @@ -759,49 +772,50 @@
<t>
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.
</t>
<t>
Validation of the instance against this keyword
on its own always succeeds, regardless of the
validation outcome of against its subschema.
If <xref target="annotations">annotations</xref>
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".
</t>
</section>
<section title="then">
<t>
This keyword's value MUST be a valid JSON Schema.
</t>
<t>
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.
</t>
<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
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.
</t>
</section>
<section title="else">
<t>
This keyword's value MUST be a valid JSON Schema.
</t>
<t>
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.
</t>
<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
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.
</t>
</section>
</section>
Expand Down