Extending properties

[epoberezkin]

Allow adding property schemas in referenced schemas.

That's one more solution to solving additionalProperties problem, somewhat similar to $params discussed with @handrews (#322). Also can be seen as implementation of a more generic #313.

Example:

Schema 2 explicitly allows extension (maybe it should be allowed by default and to prohibit extension you have to explicitly use "$extend": false (to prohibit extension of any keyword) or "$extend": {"properties": false} (to prohibit extension of properties only).

Schema 1 references schema 2 and extends properties.

{
  "$id": "schema1",
  "allOf": [{
    "$ref": "schema2",
    "$extend": {
      "properties": {
        "bar": {"type": "string"}
      }
    }
  }]
}

  "$id": "schema2",
  "$extend": {"properties": true},
  "properties": {
    "foo": {"type": "string"}
  },
  "additionalProperties": false
}

Probably other keywords can be extended in a similar way: patternProperties, required, dependencies, enum, type (with array syntax? more for consistency), items (with array syntax), anyOf, etc. - essentially any keyword that takes a structured value but not a schema.

[epoberezkin]

Maybe: "$extend": true - to allow any extension; "$extend": ["properties"] - only allow extending "properties" keyword (usage in the referenced/2nd schema).

[Anthropic]

Nice @epoberezkin I was literally thinking about suggesting this last night only as $extends where it $ref'd a schema and it's own properties overrode any on the one it was extending.

for example

properties: {
  home: {
    $extends: "definition/phone",
    "title": "Home Number"
  },
  mobile: {
    $extends: "definition/phone",
    "title": "Mobile Number"
  }
},
definition: {
  phone: {
    type: "string",
    pattern: "" //pattern for matching any phone number type
  }
}

 

But I can certainly see benefit in selecting optional include and exclude as well so I'd be supportive of this if allowing extension was the default.

Do you see any issues with making $ref behave differently based on another param in regards to backwards compatibility?

[handrews]

VOTE-A-RAMA!!!

It's time to gauge community support for all re-use/extension/additionalProperties proposals and actually make some decisions for the next draft.

Please use emoji reactions ON THIS COMMENT to indicate your support.

• You do not need to vote on every proposal
• If you have no opinion, don't vote- that is also useful data
• If you've already commented on this issue, please still vote so we know your current thoughts
• Not all proposals solve exactly the same problem, so we may end up implementing more than one

This is not a binding majority-rule vote, but it will be a very significant input into discussions.

Here are the meanings for the emojis:

• Celebration / Hooray / Tada!: I support this so strongly that I want to be the primary advocate for it
• Heart: I think this is an ideal solution
• Smiley face: I'd be happy with this solution
• Thumbs up: I'd tolerate this solution
• Thumbs down: I'd rather we not do this, but it wouldn't be the end of the world
• Frowny face: I'd be actively unhappy, and may even consider other technologies instead

If you want to explain in more detail, feel free to add another comment, but please also vote on this comment.

The vote should stay open for several weeks- I'll update this comment with specifics once we see how much feedback we are getting and whether any really obvious patterns emerge.

[erayd]

This suggestion does seem slightly confusing in that it seems to use the $extend keyword for two different purposes - it's both a permissions filter (i.e. whether extending is allowed, and if so which elements may be extended), and a definition for the actual extension data.

If this is added, my preference would be for this to be two keywords (e.g. $allowExtend for the permissions stuff and $extend for the data).

[handrews]

@erayd thanks! I think we really just need to gauge support for general directions at this point. Nearly all of the proposals would need at least a little more work. Thanks for the clarification!

[erayd]

Yeah, I got that impression while reading over the proposals and voting. It does look like things are moving along on this though, which is nice - I badly want some kind of inheritance-with-override mechanism, so very pleased to see some action happening in this area.

[handrews]

Closing this as everyone who voted, including the author, voted against it :-)

[epoberezkin]

thumb-down wasn't "against" according to your legend ;)

[handrews]

thumb-down wasn't "against" according to your legend ;)

Well, not quite "against", but given the competition, if the best an idea can get is "Meh, I won't give up on the project if this is implemented" then it's not worth keeping. Although when I get around to consolidating the ideas for draft-08 feel free to take another run at it, I suppose.

Actually I'm really hoping someone else will run draft-08 validation.