allOf in the use of "items" can't be overridden. about json-schema-validator

[fge]

Hello,

There is something I don't quite understand in your schema; mainly, this part:

"anchors": {
      "type": "array",
      "items": {
        "allOf": [
          {
            "$ref": "../../spidacalc/calc/anchor.schema"
          }
        ],
        "properties": {
          "clientItem": {
            "$ref": "../../spidacalc/client/anchor.schema"
          }
        }
      }
    }

In a same schema, you define all three of type, items and properties.

Given that type is array, the properties there will be ignored...

What is more, in items here you can drop the allOf. The whole schema for anchor can be simplified to:

{
    "type": "array",
    "items": { "$ref": "../../spidacalc/calc/anchor.schema" }
}

[toverly]

Maybe I am doing it slightly wrong, but you said:

"Given that type is array, the properties there will be ignored..."

However the anchorS are an array, but I am defining the anchors.items.properties NOT anchors.properties. I thought what I am doing is saying:

If you have an array of anchors, each item must be all of "calc/anchor", but the "clientItem" must be from "client/anchor".

I understand that the language is a little confusing without being familiar with what them mean.

[fge]

Now that I saw the test case you proposed, I know what is going on.

allOf is a keyword like any other. It is unaware of having "siblings" at all. So, if you do:

{
    "type": "object",
    "allOf": [ { "type": "string" } ]
}

(which is what happens with $ref since it is an in-place substitution ultimately), the instance will have to obey both keywords. Here, no schema can ever match, of course ;)

Schema overriding is sure quite a pain to achieve.

Also, I have been saying crap, sorry:

Given that type is array, the properties there will be ignored...

This is not what happens. properties will be evaluated, but only if the type of the instance is "object". It may be. But then type kicks in (it can kick in before or after; my implementation doesn't apply keywords in any defined order), which applies to all instance types, and its contract is to not let anything pass which is not an array...

[fge]

As to overriding, I do have an idea of a non standard extension... That would be adding support for merge-patch with something like this:

{
    "merge": {
        "schema": { "JSON Schema": "here" },
        "with": { "merge-patch": "here" }
}

This keyword would be like $ref in the sense that any other keywords would be ignored; the schema, which could be a JSON reference, would then be patched. For instance, say that at foo://bar# you have schema:

{
    "type": "string"
}

and you have this in another schema:

{
    "merge": {
        "schema": { "$ref": "foo://bar#" },
        "with": { "type": "string" }
    }
}

the resulting schema would then be:

{ "type": "string" }

I think I'll propose that for draft v5.

Also, I already have full JSON Patch support, which is more powerful than merge-patch but harder to write. I could even make a patch keyword similar to merge but which would apply a full JSON Patch instead.

[fge]

Can this issue be closed?

[fge]

-ETIMEOUT...