"Extending" definitions with other properties

[uncenter]

I bet this is a common question but I wasn't able to figure out exactly what I was hoping for. I'm trying to "extend" a defined "type" (something in "$defs") with some other properties:

{
	"$schema": "http://json-schema.org/draft-07/schema#",
	"type": "object",
	"properties": {
		"test": {
			"type": "array",
			"items": {
				"type": "object",
				"allOf": [{ "$ref": "#/$defs/myDefinition" }],
				"properties": {
					"foo": { "type": "string" },
					"bar": { "type": "string" }
				},
				"oneOf": [
					{
						"required": ["foo"]
					},
					{
						"required": ["bar"]
					}
				],
				"additionalProperties": false
			}
		}
	},
	"$defs": {
		"myDefinition": {
			"type": "object",
			"properties": {
				"baz": { "type": "boolean" }
			}
		}
	}
}

The idea here is to extend myDefinition, which has a single property baz, with properties foo and bar (either foo or bar is required, and baz is optional). In this case, these would be valid.

{
	"test": [{ "foo": "abc" }]
}

{
	"test": [{ "foo": "abc", "baz": true }]
}

{
	"test": [{ "bar": "abc", "baz": false }]
}

The "allOf": [{ "$ref": "#/$defs/myDefinition" }], is from https://stackoverflow.com/a/52579526/17378715, not sure how I should get this to work.

Thanks!

[gregsdennis]

There's not a solution for draft 7, but if you can update to draft 2020-12, you'll get the unevaluatedProperties keyword to replace additionalProperties.

The benefit of unevaluatedProperties is that it can "see inside" of subschemas, including through $refs. additionalProperties can only see the immediate subschema, not subschemas that it contains or references.

So unevaluatedProperties will pick up baz as a defined properties, but additionalProperties won't.

You can try this at https://json-everything.net/json-schema.

This passes

{
  "test": [
    {
      "foo": "ad",
      "baz": false
    }
  ]
}

This fails

{
  "test": [
    {
      "foo": "ad",
      "bar": "a string",
      "baz": false
    }
  ]
}

[gregsdennis]

I'm now wondering what additionalProperties does that unevaluatedProperties can't do.

The only difference between the two is what they see:

• additionalProperties can see properties defined by sibling keywords.
• unevaluatedProperties can see properties defined by sibling keywords and their subschemas.

That is, is there a situation in which I should pick the former instead of the latter?

If you don't want to look at properties defined by subschemas of sibling keywords, then use additionalProperties. I can't think of a scenario when this would be useful off the top of my head, but I'm sure some situation would call for it.

[gregsdennis]

As a final addendum, you can change the base addon schema to always pass. I think this gives a clearer error that it's the unevaluatedProperties that's causing the failure rather than the $dynamic*.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/baseSchema",
  "type": "object",
  "properties": {
    "test": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "baz": { "type": "boolean" }
        }
        "$dynamicRef": "#addons",
        "unevaluatedProperties": false
      }
    }
  },
  "$defs": {
    "defaultAddons": {
      "$dynamicAnchor": "addons"
    }
  }
}

Here the defaultAddons definition will always pass, which is fine. Since it doesn't define any new properties, the unevaluatedProperties will still fail.

The only thing this doesn't do is support the OO notion of an "is a" relationship. For example, a schema that represents a Vehicle won't validate a Car; you'd need to have the Car schema. This is the sticking point for a lot of people, and it's something we still haven't figured out how to model just yet.

[jdesrosiers]

There's a typo in the above example. "$dynamicRef": "addons" should be "$dynamicRef": "#addons".

[gregsdennis]

Ah, yes. I made that correction locally, but it seems it didn't make it over here.

[Relequestual]

Also worth noting that "applicators" is defined in the specification. t sounds like we are getting to the point where reading the specification might be useful, even if all of it doesn't make sense the first read through.