mokkabonna / json-schema-merge-allof

Simplify your schema by combining allOf
97 stars 23 forks source link

Impossible to write resolver that ignores values coming from allOf items #7

Open grv87 opened 4 years ago

grv87 commented 4 years ago

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 commented 4 years ago

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

mokkabonna commented 4 years ago

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.