Skip to content

Draft 7 $ref at root with sibling definitions #622

@gregsdennis

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions