Put boundaries on lack of "$schema" behavior #1353
Conversation
jsonschema-core.xml
Outdated
| but MUST fall within the following options: | ||
| <ul> | ||
| <li>Refuse to process the schema, as with unsupported required vocabularies | ||
| <li>Assume a specific, documented meta-schema |
There was a problem hiding this comment.
I'll just point out that under this language, it is still valid behavior to proceed with validation and consider all instances valid, or all instances invalid (because I can document my specific documented meta-schema is {} or an equivalent of {"not": {}}).
I don't see that as an issue personally, I think there are reasonable reasons that may make sense, but will mention it explicitly since I know there was argument about those cases and whether they're desired behavior or not.
There was a problem hiding this comment.
Yeah, the main issue is that we can't, in the core spec, restrict the options to just the standard meta-schemas. There are perfectly good reasons to default to something non-standard (e.g. OpenAPI's dialect). There are endless ways to write always-passing and always-failing schemas, so trying to forbid those feels like a bit of a lost cause.
Requiring that one document the meta-schema should at least highlight the possibility, and I suspect people would feel a bit silly documenting {} as their default meta-schema. But at least it would be clear.
This may well change prior to the next release, but documents the intended range of options so as to avoid crashes or completely arbitrary behavior.
handrews
force-pushed
the
dollarschema
branch
from
13f1458
to
69dd9a2
Compare
| Validators should take care that the parsing and validating against schemas does not consume excessive | ||
| system resources. | ||
| Validators MUST NOT fall into an infinite loop. | ||
| Implementations should take care that the parsing and evaluating against schemas |
There was a problem hiding this comment.
Phrases like "evaluating against"/"evaluated against"/etc. occur throughout the spec, and I was avoiding changing anything but validate->evaluate. I agree that the terminology is not great, but the need to choose better terminology and use it consistently is already being tracked as issue #922, so I'd rather not mess with it in this PR.
gregsdennis
added
clarification
Fixes #1315
This may well change prior to the next release, but documents the intended range of options so as to avoid crashes or completely arbitrary behavior. I believe it covers the observed behavior of implementations in the wild, so even though there is a new MUST I don't think it would cause a problem.