Is it valid to mix dialects?

[flaksp]

Hello.

The way the spec describes usage of the $schema keyword in subschemas is too confusing for me. I believe JSON Schema Blog needs some clarification about this 😇

Are these cases valid according to the spec?

New draft references old draft

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$ref": "#/$defs/old",
  "$defs": {
    "old": {
      "$schema": "https://json-schema.org/draft/2019-09",
      "type": "string"
    }
  }
}

Will something change if I add $id keyword to the schema defined at #/$defs/old?

Old draft references new draft

{
  "$schema": "https://json-schema.org/draft/2019-09",
  "$ref": "#/$defs/new",
  "$defs": {
    "new": {
      "$schema": "https://json-schema.org/draft/2020-12/schema",
      "type": "string"
    }
  }
}

New draft references side loaded old draft

{
  "$schema": "https://json-schema.org/draft/2019-09",
  "$id": "https://example.com/old"
  "type": "string"
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$ref": "https://example.com/old"
}

[handrews]

It's pretty confusing, TBH.

You can always $ref a separate document that is of a different draft. Each document (file or complete HTTP response, for example) is processed independently, so each is processed by its own $schema.

As of 2020-12, you can have an embedded resource within a document ($id in a subschema) with a different $schema from the root. This is a tricky case to handle, so you need to test the implementations you're using to see if they handle it correctly.

So to answer your cases:

• $schema in a random subschema without $id: Not valid (I think not in any draft, although there might be one where it was a "SHOULD NOT" and the behavior was undefined)
• $schema in a subschema with $id: Valid in 2019-09 and earlier if $schema is the same as the $schema at the root, valid in 2020-12 even with a different value for $schema, although definitely check your implementation to see if this is properly supported as it's weird and tricky
• side by side documents referencing each other: Valid with any combinations of $schema values

[jdesrosiers]

$schema in a subschema with $id: Valid in 2019-09 and earlier if $schema is the same as the $schema at the root, valid in 2020-12 even with a different value for $schema

I disagree that the dialect can't change in 2019-09. The nature of $id in sub-schemas changed in 2019-09 to be an embedded schema rather than just a base URI change. An embedded schema has all the same abilities as a normal schema you would reference including the ability to declare its dialect.

It wasn't specifically mentioned that a dialect can change in an embedded schema until 2020-12 when the bundling section was added, but it was possible in 2019-09 as a natural consequence of how sub-schema $ids are defined. The text in 2020-12 wasn't intended to be a behavior change.

[handrews]

@jdesrosiers 2019-09 is the "implementation-defined" draft:

If multiple schema resources are present in a single document, then
all schema resources SHOULD Have the same value for "$schema". The
result of differing values for "$schema" within the same schema
document is implementation-defined.

(apologies for the added/deleted comments, I kept getting the documents mixed up)

[jdesrosiers]

I stand corrected. I must have missed that.

[handrews]

@jdesrosiers given that it took me literally three tries to find the right quote, I think that's understandable!

[jdesrosiers]

The Understanding JSON Schema documentation covers this concept in a more approachable way than the spec, https://json-schema.org/understanding-json-schema/structuring.html#bundling.