Is there a strict mode to decline extra data in JSON?

[shaunwarman]

We see that extra data added outside the scope of the schema is allowed and passes ajv validation. Is there a way to block this?

Schema:

"actor_type": {
  "type": "array",
  "items": {
    "type": "object",
    "@template_id": "PCE-87549f5c-b38c-4dc1-ae90-c8a4f73d40eb",
    "properties": {
      "object_id": {
        "type": "string",
        "enum": [
          "*",
          "ADMIN"
        ]
},

JSON configuration:

{  
   "actor_type":[  
      {  
         "object_id":"ADMIN",
         "capability_group":{  
            "capability_sets":[  
               {  

               }
            ]
         },
         "capabilities_set":false,
         "operation_set":false
      }
   ]
}

It looks like the added values of capability_group and capability_sets are extra data that aren't in the JSON schema and pass ajv validation. Is there a flag or way around this to not allow extra data here?

[epoberezkin]

You need to use additionalProperties keyword in the schema.

There is no such thing as strict mode in the standard. By default additional properties are allowed.

[shaunwarman]

Perfect, just missed that. Thanks!

[hatfinch]

additionalProperties doesn't work, though, when you're trying to combine different schema definitions (see https://spacetelescope.github.io/understanding-json-schema/reference/combining.html#allof, "Unfortunately, now the schema will reject everything. This is because the Properties refers to the entire schema. And that entire schema includes no properties, and knows nothing about the properties in the subschemas inside of the allOf array".)

That page goes on to say "This shortcoming is perhaps one of the biggest surprises of the combining operations in JSON schema: it does not behave like inheritance in an object-oriented language. There are some proposals to address this in the next version of the JSON schema specification". However, I can't find any indication of consensus within the json-schema community about how to move forward with this. A "strict mode" in AJV would bridge that gap.

[epoberezkin]

@hatfinch please see #134 (comment)

[hatfinch]

Thank you for your response!

I don't think any of the proposed solutions described at that link really fit my use case.

I have something like the (simplified) following:

{
  "definitions": {
    "boat": {
      "properties": {
        "sail": {
          "type": "boolean"
        }
      }
    },
    "car": {
      "properties": {
        "towbar": {
          "type": "boolean"
        }
      }
    },
    "motorbike": {
      "properties": {
        "saddles": {
          "type": "number"
        }
      }
    },
    "vehicle": {
      "properties": {
        "owner": {
          "type": "string"
        }
      },
      "anyOf": [
        {
          "$ref": "#/definitions/wheeledVehicle"
        },
        {
          "$ref": "#/definitions/boat"
        }
      ]
    },
    "wheeledVehicle": {
      "properties": {
        "numberOfWheels": {
          "type": "number"
        }
      },
      "anyOf": [
        {
          "$ref": "#/definitions/bus"
        },
        {
          "$ref": "#/definitions/car"
        }
      ]
    }
  }
}

Your solution #1 at that link, "don't worry about additionalProperties and simply allow them", comes closest: I'm really only looking for strictness.

(It's possible that $merge could be used, but I can't see how to go that route without it ending up more verbose than just defining numberOfWheels and owner in multiple places. It's not a question of whether we can express what we want to express, it's a question of how succinctly we can express it.)

additionalProperties tries to do more than that, though: Henry Andrews provides a good explanation of them at https://groups.google.com/forum/#!searchin/json-schema/additionalProperties|sort:relevance/json-schema/dDkozAUTxRk/YuqEvjXuAAAJ -- mine is #2.

As he says, "First, we need to make it possible to distinguish between use cases #1 and #2. Currently we do not have inheritance (allOf is more of an intersection operator). So I would say that “additionalProperties: false” on its own should indicate #2: the desire for strict validation of property names. That is it’s most clear current effect, and many, many JSON Schema users have indicated that that is why they use “additionalProperties: false”."

It seems to me that although it's difficult to obtain consensus on how to achieve strictness in the spec, the tools could allow it as a global option, and that this would be useful to "many, many JSON Schema users".