-
I'm working on an implementation and while trying to pass the test suite I found that there is something I don't quite understand regarding the infinite loop detection tests. The tests included under the infinite loop detection files don't seem to actually describe any infinite loop. Actually, the tests state clearly that the case covered does not imply any infinite loop:
I can imagine that a schema that creates a loop isn't actually a valid schema: {
"$comment": "This is not a valid schema. Please don't judge me for writing it",
"$schema": "https://json-schema.org/draft/next/schema",
"$defs": {
"a": {
"$ref": "#/$defs/b"
},
"b": {
"$ref": "#/$defs/a"
}
},
"properties": {
"a": {},
"b": {}
},
"required": [
"a",
"b"
]
} How are implementations handling this? I guess an error rejecting to validate a schema with such a loop is the correct way, as the specification says:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The most reasonable validator behavior is to apply both schemas, not following references to schemas that have already been visited. In this example, apply "a" without following the reference to "b", and also apply "b" without following the reference to "a". Now, some validators (presumably) do something else, and the behavior is undefined perhaps because changing one behavior to conform to the other would cause more problems than it solves. (This could be revisited, there's probably very few people who depend on a validator erroring for schemas like this.)
"Schemas" here is a directive for schema authors, not validators. And when the spec says "the behavior is undefined" it means there is no incorrect way to handle it—so any test for this would be incorrect. |
Beta Was this translation helpful? Give feedback.
The most reasonable validator behavior is to apply both schemas, not following references to schemas that have already been visited. In this example, apply "a" without following the reference to "b", and also apply "b" without following the reference to "a".
Now, some validators (presumably) do something else, and the behavior is undefined perhaps because changing one behavior to conform to the other would cause more problems than it solves. (This could be revisited, there's probably very few people who depend on a validator erroring for schemas like this.)