$ref resolution in Compound Schema Documents

[dylankerr-bis]

There have been some issues raised here in the past in regards to Compound Schema Documents/bundles, but it looks like the support has been significantly improved since then. Although it mostly works as I would expect, I've run into an issue with how some $refs are resolved.

Suppose I call:

jsonSchemaFactory.getSchema(SchemaLocation.of(
        "http://example.com/schemas/v3/bundle.json#/$defs/http:~1~1example.com~1schemas~1v3~1component~1foo"));

and http://example.com/schemas/v3/bundle.json returns the following 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 correctly resolving to http://example.com/schemas/v3/component/bar.

The $ref from http://example.com/schemas/v3/component/bar to "./baz" should resolve to http://example.com/schemas/v3/component/bat but is incorrectly resolving to http://example.com/schemas/v3/bat. I have traced this to RefValidator.resolve, which in the case of nested schema resources, resolves references relative to the parent schema, which means in this case resolving relative to http://example.com/schemas/v3/bundle.json instead of http://example.com/schemas/v3/component/bar.

Based on the "$ref prevents a sibling $id from changing the base uri" comment, this seems to be intentional, but it does seem to be incorrect from my reading of the spec.

Would it be possible to clarify if this is intentional behaviour, and either fix it or suggest a workaround?

Thanks for an excellent library otherwise!

[justin-tay]

Intentional behaviour. This comes from a test from the JSON-Schema-Test-Suite

• https://github.com/json-schema-org/JSON-Schema-Test-Suite/blob/02a0d89f6e1d6e864028d7e497b8ee6b63eaca19/tests/draft7/ref.json#L179

You can put the $ref in an allOf.

[dylankerr-bis]

Interesting, I hadn't seen that. It looks like that test is not present in the draft 2019-09 or draft 2020-12 test suites - which I suspect coincides with the introduction of the Compound Schema Document as a concept.

Would you consider having the behaviour depend on the active JSON Schema version? I appreciate there's some complexity there since different schema resources in the same document can use different versions of JSON Schema.

You can put the $ref in an allOf.

I will use this workaround for now, thank you!

[justin-tay]

You will have to get them to add a test case in the test suite with your expected behaviour, only then will this library will be changed to be compliant.