Draft 7 $ref at root with sibling definitions

[gregsdennis]

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.

[jdesrosiers]

It was determined that the behavior in this case is implementation defined. See, #458