Conditionally apply additionalProperties on child but not on parent that references it - json

Question

I am looking to implement two schemas, one of which is an array of the other, let's call this Payload B and the other Payload A.
The problem: The parent schema requires an additional key, which the child schema cannot allow.
Payload A:
{
"a": "a",
"b": "b",
"c": "2019-05-01T09:00:00Z"
}
implemented with a schema of:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "item-schema.json",
"title": "Individual Item POST",
"description": "",
"type": "object",
"properties": {
"a": {
"type": "string"
},
"b": {
"type": "string"
},
"c": {
"type": "string",
"format": "date-time"
}
},
"additionalProperties": false,
"required": [
"a",
"b",
"c"
]
}
Payload B:
[
{
"a": "aa",
"b": "bb",
"c": "2019-05-01T10:00:00Z",
"d": "dd"
},
{
"a": "aaa",
"b": "bbb",
"c": "2019-05-01T11:00:00Z",
"d": "ddd"
}
]
implemented with a schema of:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"$id": "items-schema.json",
"title": "Multiple Item POST",
"description": "",
"type": "array",
"items": {
"allOf": [
{
"$ref": "item-schema.json"
},
{
"properties": {
"d": {
"type": "string"
}
}
}
]
},
"additionalItems": false
}
The issue I have is that whilst Payload A is validated correctly in that it doesn't allow any extraneous keys, Payload B is invalid due to Payload A's schema.

Answer 1

The only way to achieve what you want with draft-7 JSON Schema is to have duplication in your schema.
You would need to modify the allOf/1 to have properties:a,b,c:true (remember, booleans are schemas) and add additionalProperties:false.
AND you would have to remove additionalProperties:false from item-schema.json.
If you can't do that and you need item-schema.json to work on its own, then I'm sorry: you're out of luck, so you'll have to duplicate the schema rather than reference it.
Recognising that this is not super great, we worked hard (I approved the PR. Props to the rest of the core team!) to create a new keyword for draft-8 unevaluatedProperties. You can read about it at https://github.com/json-schema-org/json-schema-spec/issues/556.
If it's any consolation, the OpenAPI Specification has the same issue, which is explained in the issue referenced above.