excludedProperties support would be benificial

[barkermn01]

It would be good if we could get support for certain properties to be forbidden.

I was working with someone last night and found a use case where forbidden properties would be useful.
He was unable to disable additionalProperties however had 2 difference cases. in the same schema.

this was the end result

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": [
    "app_id"
  ],
  "oneOf": [
    {
      "properties": {
        "app_id":{
          "type": "string",
          "pattern": "^[0-9]{10}$"
        },
        "my_id": {
          "type": "string",
          "pattern": "^[0-9]{8}$"
        }
      }
    },
    {
      "properties": { 
        "app_id":{
          "type": "string",
          "pattern": "^[0-9]{10}$"
        },   
        "m_id": {
          "type": "string",
          "pattern": "^[0-9]{9}$"
        }
      }
    }
  ]
}

however his test payload caused it to validate against both test payloads.
Payload 1

{
  "app_id":"1234567890",
  "my_id":"12345678",
}

Payload 2

{
  "app_id":"1234567890",
  "m_id":"123456789",
}

Idealy there we should have a an exclusions list. excludeProperties:["propertyName", "property2Name"] so the inital schema could look like.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": [
    "app_id"
  ],
  "oneOf": [
    {
      "properties": {
        "app_id":{
          "type": "string",
          "pattern": "^[0-9]{10}$"
        },
        "my_id": {
          "type": "string",
          "pattern": "^[0-9]{8}$"
        }
      },
      "excludeProperties":["m_id"]
    },
    {
      "properties": { 
        "app_id":{
          "type": "string",
          "pattern": "^[0-9]{10}$"
        },   
        "m_id": {
          "type": "string",
          "pattern": "^[0-9]{9}$"
        }
      },
      "excludeProperties":["my_id"]
    }
  ]
}

This would then allow for easier versions of Schema so if your building an API Endpoint that you then wish to upgrade as your new schema could be in the "oneOf" allowing addditionalProperties and still identify easily which one of the oneOf's it is.

This could be added to the schema simply
"excludedProperties": { "$ref": "#/definitions/stringArray" },

Example Specification definition

<section title="excludedProperties">
    <t>The "excludedProperties" keyword functions as both an annotation (Section 3.3) and as an assertion (Section 3.2). While no special effort is required to implement it as an annotation conveying semantic meaning, implementing validation is non-trivial.</t>

    <t>Validation with "excludedProperties" applies only to the child values of instance names that do not match any names in "properties", and do not match any regular expression in "patternProperties".</t>

    <t>This keyword determines how child instances validate properties and do not directly validate the immediate instance itself.</t>

    <t>For all such properties, validation fails if the child instance contains a property by name supplied against the "excludedProperties".</t>

    <t>Omitting this keyword has the same behaviour as an empty schema.</t>
</section>

[handrews]

The syntax to forbid a property is simply to set its schema to the boolean false schema. This works with patternProperties as well (and the tuple form of items, although the uses for that are rather less common).

So your example becomes:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": [
    "app_id"
  ],
  "oneOf": [
    {
      "properties": {
        "app_id":{
          "type": "string",
          "pattern": "^[0-9]{10}$"
        },
        "my_id": {
          "type": "string",
          "pattern": "^[0-9]{8}$"
        },
        "m_id": false
      }
    },
    {
      "properties": { 
        "app_id":{
          "type": "string",
          "pattern": "^[0-9]{10}$"
        },   
        "m_id": {
          "type": "string",
          "pattern": "^[0-9]{9}$"
        },
        "my_id": false
      }
    }
  ]
}

which does exactly what you want.

You may also be interested in #556 unevaluatedProperties proposed for draft-08, which is similar to additionalProperties but works across oneOfs like this in the way you probably wanted when you tried to use "additionalProperties": false here. But it's best to use the least powerful tool in general, so for this simple case I'd stick with setting individual properties to false where needed.

[tgoraknath]

@handrews - let me evaluate above schema whether it fits all permutations. Here is the alternative I utilized to achieve all the permutations to work with.

{
"$schema":"http://json-schema.org/draft-07/schema#",
"type": "object",
"oneOf":[
{"$ref": "#/definitions/v0"},
{"$ref": "#/definitions/v0_1"}
],
"definitions": {
"v0": {
"type": "object",
"required": ["app_id","m_id"],
"properties": {
"app_id": {"type": "string", "pattern":"^[0-9]{10}$"},
"m_id": {"type": "string", "pattern":"^[0-9]{8}$"}
}
},
"v0_1": {
"type": "object",
"required": ["app_id","my_id"],
"properties": {
"app_id": {"type": "string", "pattern":"^[0-9]{10}$"},
"my_id": {"type": "string", "pattern":"^[0-9]{9}$"}
}
}
}
}

[handrews]

Those will also work with the oneOf because of how you have arranged the "required" fields. Often that will be enough, occasionally you will need to forbid a property with a false.

[tgoraknath]

Hi @handrews, can we avoid duplicate entry of app_id definitions in the schema that you have shared? I mean to say for root object can we utilize properties element to define app_id and remove app_id from oneOf?

[tgoraknath]

Hi @handrews, A small modification to the schema that u shared and works fine. however setting attribute to false is something I worried about bcz in ideal world we need to deal with simple and complex elements and developers can go wrong with complex structure and documentation, understanding can go wrong.

How about support for this schema for nodejs - jsonschema package - v: 1.2.4

schema_ex_2.txt

[handrews]

@tgoraknath

This should work:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": [
    "app_id"
  ],
  "properties": { 
    "app_id":{
      "type": "string",
      "pattern": "^[0-9]{10}$"
    }
  },
  "oneOf": [
    {
      "properties": {
        "my_id": {
          "type": "string",
          "pattern": "^[0-9]{8}$"
        },
        "m_id": false
      }
    },
    {
      "properties": { 
        "m_id": {
          "type": "string",
          "pattern": "^[0-9]{9}$"
        },
        "my_id": false
      }
    }
  ]
}

I'm not entirely sure I follow your concerns about simple and complex structures, but the reason that we made the boolean true and false schemas legal anywhere a subschema can be present (instead of just as special case values of additionalProperties and additionalItems) is to allow schema authors to clearly and unambiguously convey intent.

Unlike the functionally equivalent {} and {"not": {}}, both humans and parsers can easily recognize that true means that absolutely anything is allowed, and false means that the entire thing with this subschema is absolutely forbidden.

Schema implementations are encouraged to optimize these cases and use them to help produce better error messages (e.g. "property "x" is forbidden" for "x": false instead of "value {blah...} for property "x" fails against subschema whatever").

If that still does not convince you, perhaps you could give a detailed example of how someone would be confused?

[tgoraknath]

Thanks you @handrews! I am good with the answers and appreciate your support.

I will share outside of this PR bcz it will deviate the purpose of this PR. Let me know if can reach you out on https://json-schema.slack.com.

[handrews]

Let me know if can reach you out on https://json-schema.slack.com.

please do!