json-schema-merge-allof icon indicating copy to clipboard operation
json-schema-merge-allof copied to clipboard

Impossible to write resolver that ignores values coming from allOf items

Open grv87 opened this issue 5 years ago • 2 comments

I think that the best way to handle fields title, description and examples is to preserve what is declared in the schema itself and ignore everything coming from allOf items.

Consider the following schema:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "definitions": {
    "developer": {
      "title": "Developer",
      "description": "A nerd",
      "type": "object",
      "properties": {
        "knowsLanguages": {
          "type": "array",
          "items": { "type": "string" }
        }
      }
    },
    "manager": {
      "title": "Manager",
      "description": "People person",
      "type": "object",
      "properties": {
        "maxNumberOfSubordinates": { "type": "number" }
      }
    }
  },
  "title": "Team",
  "properties": {
    "teamLeader": {
      "description": "The Boss",
      "allOf": [
        {
          "$ref": "#/definitions/developer"
        },
        {
          "$ref": "#/definitions/manager"
        }
      ]
    }
  }
}

If we resolve $refs and run merge, we got title copied from the first type (Developer). This just makes no sense.

So, I need a custom resolver that could detect whether value comes from parent schema (and keep it) or from items of allOf (and ignore it).

The problem is that it is impossible having current set of arguments resolver is called with. Please, add a way. Or, better, make this behavior as default.

grv87 avatar Sep 16 '19 20:09 grv87

In JSON Schema Validation draft 07 such keywords are named annotation keywords (as opposed to validation).

grv87 avatar Sep 17 '19 15:09 grv87

I see what you are saying, and agree that something like that is needed.

I do not favor making it the default behavior, I think choosing the first is the most straight forward approach.

I think maybe changing the path array to contain the full path to the individual values in different allOf schemas is the way to go. Only worried about backwards compability. Maybe introduce a new variable..

Anyway: I do not currently have too much time to do just that, suggestions are welcome.

mokkabonna avatar Sep 20 '19 08:09 mokkabonna