-
-
Notifications
You must be signed in to change notification settings - Fork 221
Description
We don't have a test that ensures implementations don't scan for nested schema objects or schema resources (if that's indeed the requirement).
{
"$ref": "#/definitions/reference",
"definitions": {
"reference": { "type": "integer" }
}
}
I suppose this would be okay since the reference is just a pointer into data that happens to be itself, but if it were a reference to a nested $id
(with either a URI base change or an anchor), it would definitely fail.
We do have a test to make sure that a sibling $id
doesn't change the base URI, but the $ref
in question isn't at the root, so would
{
"$id": "http://example.com/base",
"$ref": "myInteger#/definitions/integer",
}
ignore the $id
? What would the base URI be, then?
(I suspect things like this were a factor in the reason we decided to allow sibling keywords, but we still need to know how this works.)
The spec merely says:
All other properties in a "$ref" object MUST be ignored.
I expect the anticipation was (as was common practice at the time) to wrap a root reference in an allOf
.
This comes out of an old user test of mine that has a case similar to the top example. I encountered it after refactoring my reference management a bit. I didn't notice the root-level $ref
at the time.