Can a schema parameter's 'required' attribute be overridden?

I have a common object defined in schemas referenced in a couple of endpoints. However, the specific set of required fields differ between the references. For example, one endpoint requires properties foo and bar, while another endpoint requires properties foo and qux.

Is it possible to override the required list when referencing a schema? Is there another fairly DRY way to accomplish this? (The only workaround I can think of is inlining the schema everywhere, which leads to duplication and possibility of inconsistencies.)

If it’s not possible, could this be implemented?

[handrews]

Yes, since foo is required in both cases, have "required": ["foo"] in your re-usable schema under components, and then use allOf to reference the re-usable schema and also add "required": ["bar"] or "required": ["qux"] or whatever.

https://tools.ietf.org/html/draft-wright-json-schema-validation-01#section-6.26

[handrews]

@emvau the schemas in an allOf are each evaluated separately, and must all pass. There is no “overriding” here, you just add constraints in each branch of the allOf. In practical terms for required, this just means that you can’t use allOf to remove a requirement.

As for nesting, the 2nd schema under allOf in your example reads as:

• if the instance is an object, then…
• if it has a "vehicleOffers" property which is an array, then…
• if an entry in the array is an object with a "vehicles" property which is itself an array, then…
• if an entry in the "vehicles" array is an object, then it must have a property named "options"

The reason for all of the ifs is that properties and items do not force the instance to be of type object or array, respectively. They apply only if the instance is of the appropriate type. To force the types throughout, you need to set type (or maybe it is already set in the offer.json schema, in which case you do not need to re-set it in the other schema. This is type-related behavior covered in the JSON Schema specification.

Note that requiring "options" at the deepest level does not cause any higher level properties to be required. You would need to set required at each level to do that (and presumably "minItems": 1 on arrays if you want to ensure there is always at least one vehicle in a vehicle offer).