Clarification needed - Sibling $id and $ref in nested schema resources

[dylankerr-bis]

Prompted by networknt/json-schema-validator#1200 - relevant details copied below.

Suppose http://example.com/schemas/v3/bundle.json resolves to the following Compound Schema Document:

{
     "$defs": {
        "http://example.com/schemas/v3/component/foo": {
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "$id": "http://example.com/schemas/v3/component/foo",
            "type": "object",
            "properties": { "bar": { "$ref": "./bar" } }
        },

        "http://example.com/schemas/v3/component/bar": {
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "$id": "http://example.com/schemas/v3/component/bar",
            "$ref": "./baz",
            "unevaluatedProperties": false
        },

        "http://example.com/schemas/v3/component/baz": {
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "$id": "http://example.com/schemas/v3/component/baz",
            "type": "object",
            "properties": { "bat": { "type": "string" } }
        }
    }
}

The $ref from http://example.com/schemas/v3/component/foo to "./bar" is resolves to http://example.com/schemas/v3/component/bar.

Based on the "$ref prevents a sibling $id from changing the base uri" test, the NetworkNT validator resolves the $ref: "./baz" in http://example.com/schemas/v3/component/bar relative to the parent schema, returning http://example.com/schemas/v3/bat instead of http://example.com/schemas/v3/component/bat which I would expect.

I notice that this test is present in older versions but has been removed in draft 2019-09 and draft 2020-12.

What is the intended behaviour, and would it be possible to get a test added to clarify this?

[jdesrosiers]

The behavior of $ref changed in 2019-09. Before the change, if an object has a $ref property, the entire object is considered a reference, not a schema. Because it's not a schema, the $id (and any the other properties) has no meaning and is ignored. That's what the earlier tests are testing.

In 2019-09, it changed so that a $ref property is just a normal schema keyword and the value of the property is considered a reference. That means $id is a schema keyword and is no longer ignored. Those tests were removed in the later drafts because they no longer apply.

There are other tests that illustrate this behavior. https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/main/tests/draft2020-12/ref.json#L457-L475 is one example that has $id and $ref at the same level and even includes embedded schemas like your example. There are several more tests after it that are similar. But, that might not catch the bug you're describing because all of those tests are local references and don't need resolve against the $id.

We also have tests that check that references in embedded schemas resolve against the nearest $id, https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/main/tests/draft2020-12/refRemote.json#L78-L100. But, again, that might not catch this bug because the $ref isn't at the same level as the $id`.

We thought we had it covered, but it's possible that there's an implementation that passes all our tests, but doesn't handle this specific case. If you're willing to write up a PR to add a test for this case, it would be appreciated.

[dylankerr-bis]

Thanks for the detailed response, Jason. I will have a go at this and raise a PR.