Switching subschemas according to attribute names?

[Markus-Elfring]

I became curious also about JSON schema composition.
I am looking for another bit of clarification for the safe application of the key word “oneOf”.

• Can an attribute name be switched together so that the corresponding subschema can be adjusted?
• Would you like to add any advices for the possibility to distinguish selected data structures based on labels (or property names)?

[handrews]

@Markus-Elfring I think you are looking for propertyDependencies which will be in the next release.

[jdesrosiers]

Most of that I can't answer because I can't figure out what you're asking. For the rest, let's use a different example that is a a little more typical.

{
  "type": "object",
  "properties": {
    "type": { "enum": ["foo", "bar"] },
    "aaa": { "type": "string" },
    "bbb": { "type": "string" }
  },
  "required": ["type"],

  "allOf": [
    { "$ref": "#/$defs/type-foo-requires-aaa" },
    { "$ref": "#/$defs/type-bar-requires-bbb" }
  ],

  "$defs": {
    "type-foo-requires-aaa": {
      "if": {
        "properties": { "type": { "const": "foo" } },
        "required": ["type"]
      },
      "then": { "required": ["aaa"] }
    },
    "type-bar-requires-bbb": {
      "if": {
        "properties": { "type": { "const": "bar" } },
        "required": ["type"]
      },
      "then": { "required": ["bbb"] }
    }
  }
}

In this example, I define the full object in the first part, complex assertions in the second part, and and definitions at the end. You can read and understand this schema easily without needing to even look at the complex parts that are abstracted away in the lower parts of the schema.

By defining the complex assertions in definitions, we can give them a descriptive name and use them almost like custom keywords in the schema. You could have written these complex constraints using nested if/then/else instead of two if/thens, but that would make this schema significantly less readable than the example above.

Any time you see something you that looks like duplication in that schema, it's probably there to improve error messaging when given invalid schemas. In the case of the "type": { "enum": ["foo", "bar"] }, this is necessary because the if/then checks don't constraint "type". Someone could use "type": "something else" and the schema wouldn't complain and neither of the complex assertions would assert anything.

The pattern I'm showing isn't always the right fit for every situation. Since your example is incomplete and doesn't make sense to me, I can't tell you if it's the right fit. I can only guess. Hopefully, seeing a full example of the pattern I'm describing makes the other example I gave make a little more sense. Writing a schema is just like writing any other code. There is often more than one way to do things and people's taste and code styles will vary. You aren't bound to use my style if you prefer something else.

[Markus-Elfring]

Any time you see something you that looks like duplication in that schema, it's probably there to improve error messaging when given invalid schemas.

🔮 How is the software quality evolving for better error reporting approaches also together with JSON schemas?

Since your example is incomplete

It was constructed for further clarification of questionable implementation details according to another special use case.

and doesn't make sense to me,

🔮 How will data design imaginations evolve according to the mentioned case distinctions?

1. Attribute/property names
2. Selection of properties for (JSON) objects or arrays

I can't tell you if it's the right fit.

💭 Was this variant interesting and helpful enough for a constructive discussion?

[jdesrosiers]

Was this variant interesting and helpful enough for a constructive discussion?

I don't know what "variant" you're referring to, but no, nothing you have said has been clear enough for us to have a constructive discussion about. We're doing our best to answer your questions, but we can't understand what you want. I'm sorry, but I have to be done with this conversation for now because it hasn't been constructive and the way it's been going, I don't see that improving.

[Markus-Elfring]

…, I don't see that improving.

💭 Do you find another clarification approach worth for further development considerations?

Checking support for the key words “oneOf” and “allOf”

[Markus-Elfring]

💭 Would you like to add any comments to another clarification approach?

Improve data type determination for the key words “oneOf” and “allOf”