Embedded schemas aren't handled properly

[jdesrosiers]

I noticed that there are a couple of issues with linting schemas that include embedded schemas. Here's a minimal example where there's an embedded schema with a different dialect than the parent schema.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/main",

  "$ref": "embedded",
  "$defs": {
    "embedded": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "$id": "embedded",

      "allOf": [{ "$ref": "#/definitions/foo" }],
      "definitions": {
        "foo": { "type": "number" }
      }
    }
  }
}

EDIT: I forgot to wrap $ref in allOf for draft-07

I get the following result.

definitions was superseded by $defs in 2019-09 and later versions
Location: Line 11, Col 7
Rule ID: definitions_to_defs
Schema: /$defs/embedded/definitions

definitions was superseded by $defs in 2019-09 and later versions
Location: Line 11, Col 7
Rule ID: definitions_to_defs
Schema: /$defs/embedded/definitions

There are two problems with this response. Most obviously, it's the same error reported twice. But, also, it failed to detect the dialect change and it shouldn't be an error at all. definitions is correct for draft-07.

[jviotti]

I'll let @Karan-Palan comment on the double errors (maybe worth an e2e test case?).

On the dialect change, on my implementation, Draft 7 and earlier will ignore keywords sibling to $ref. In this case, /$defs/embedded/$ref is making /$defs/embeded/$id and /$defs/embedded/$schema ignored. Does your implementation still handle these things?

Though at the very least we can have specific linter errors for $schema and $id being ignored, just to make it more obvious.

We also have an in-progress rule to signal $ref's to invalid destinations. I think that will catch your top-level $ref if the nested identifier is indeed getting ignored.

[jviotti]

Oh actually the double report on this one is present on the CLI too for this schema. I'll take a closer look...

[jviotti]

Hm actually on the $id getting ignored, it is the same if I wrap it in allOf. I think something very wrong is going on 🤔 . The CLI inspect command DOES correctly recognise the subschema as Draft 7 (given the allOf):

(POINTER) URI: https://example.com/main#/$defs/embedded/allOf/0/$ref
    Type              : Static
    Root              : https://example.com/main
    Pointer           : /$defs/embedded/allOf/0/$ref
    File Position     : 12:11
    Base              : https://example.com/embedded
    Relative Pointer  : /allOf/0/$ref
    Dialect           : http://json-schema.org/draft-07/schema#
    Base Dialect      : http://json-schema.org/draft-07/schema#
    Parent            : /$defs/embedded/allOf/0

(POINTER) URI: https://example.com/main#/$defs/embedded/definitions
    Type              : Static
    Root              : https://example.com/main
    Pointer           : /$defs/embedded/definitions
    File Position     : 15:7
    Base              : https://example.com/embedded
    Relative Pointer  : /definitions
    Dialect           : http://json-schema.org/draft-07/schema#
    Base Dialect      : http://json-schema.org/draft-07/schema#
    Parent            : /$defs/embedded

While without the allOf (i.e. the original schema), the identifier is correctly ignored by the linter in terms of the dialect, even though the actual base URI of embedded is still getting added:

(POINTER) URI: https://example.com/main#/$defs/embedded/$ref
    Type              : Static
    Root              : https://example.com/main
    Pointer           : /$defs/embedded/$ref
    File Position     : 10:7
    Base              : https://example.com/embedded
    Relative Pointer  : /$ref
    Dialect           : https://json-schema.org/draft/2020-12/schema
    Base Dialect      : https://json-schema.org/draft/2020-12/schema

(POINTER) URI: https://example.com/main#/$defs/embedded/definitions
    Type              : Static
    Root              : https://example.com/main
    Pointer           : /$defs/embedded/definitions
    File Position     : 11:7
    Base              : https://example.com/embedded
    Relative Pointer  : /definitions
    Dialect           : https://json-schema.org/draft/2020-12/schema
    Base Dialect      : https://json-schema.org/draft/2020-12/schema
    Parent            : /$defs/embedded

[jviotti]

@jdesrosiers Actually there is an interesting conflict on the schema you are presenting here:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/main",

  "$ref": "embedded",
  "$defs": {
    "embedded": {
      "$schema": "http://json-schema.org/draft-07/schema#",
      "$id": "embedded",

      "$ref": "#/definitions/foo",
      "definitions": {
        "foo": { "type": "number" }
      }
    }
  }
}

If we consider /$defs/embedded/$schema, then /$defs/embedded/$ref must override the sibling keywords, thus overriding /$defs/embedded/$schema itself. But if we consider that the reference is on 2020-12 because the sibling $schema was overridden, then on 2020-12 it should NOT override the sibling.

I think that's the core of the problem here. The tooling is getting pretty confused.

How do other implementations handle this? Should I make $ref NOT override sibling $schema or $id but override other keywords? Seems a bit of a gray area overall

[jdesrosiers]

On the dialect change, on my implementation, Draft 7 and earlier will ignore keywords sibling to $ref.

Oops. I minimized the example a little too much. Glad you found the actual problem despite my bad example. I'll update the example.