Link to the specification: http://json-schema.org/latest/json-schema-validation.html#anchor64
Section 5.4.4.2 states:
Successful validation of an object instance against these three keywords depends on the value of "additionalProperties": if its value is boolean true or a schema, validation succeeds; ...
Section 5.4.4.3 states:
If "additionalProperties" is absent, it may be considered present with an empty schema as a value.
Ok, so if "additionalProperties" is absent, it counts as being present with an empty schema. And if it's a schema (of any kind), then the object validates successfully regardless of any other consideration.
But this is contradicted by the assertion in section 5.4.4.5, "Example", that the given instance fails to validate against the given schema (which doesn't specify anything for "additionalProperties").
Can someone explain where and in what way I'm misinterpreting the specification?
The additionalProperties keyword is used to control the handling of extra stuff, that is, properties whose names are not listed in the properties keyword or match any of the regular expressions in the patternProperties keyword. By default any additional properties are allowed.
Gets or sets a flag indicating whether the value can not equal the number defined by the minimum attribute (Minimum).
The simplest way to check if JSON is valid is to load the JSON into a JObject or JArray and then use the IsValid(JToken, JsonSchema) method with the JSON Schema. To get validation error messages, use the IsValid(JToken, JsonSchema, IList<String> ) or Validate(JToken, JsonSchema, ValidationEventHandler) overloads.
In a JSON schema, a $ref keyword is a JSON Pointer to a schema, or a type or property in a schema. A JSON pointer takes the form of A # B in which: A is the relative path from the current schema to a target schema. If A is empty, the reference is to a type or property in the same schema, an in-schema reference.
You have found an error in the spec, so your not actually misinterpreting something.
There is an updated version (from two days later) of the internet draft on the IETF website, where this example is different.
see: https://datatracker.ietf.org/doc/html/draft-fge-json-schema-validation-00#page-13
As the document is an internet draft, most likely the version on http://datatracker.ietf.org/ is the correct version.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF).
Additionally, the two versions have different dates, and expiry dates:
On the IETF version:
This schema will be used as an example:
{ "properties": { "p1": {} }, "patternProperties": { "p": {}, "[0-9]": {} }, "additionalProperties": false
This is the instance to validate:
{ "p1": true, "p2": null, "a32&o": "foobar", "": [], "fiddle": 42, "apple": "pie" }
The three property sets are:
s [ "p1", "p2", "a32&o", "", "fiddle", "apple" ] p [ "p1" ] pp [ "p", "[0-9]" ]
Applying the two steps of the algorithm:
after the first step, "p1" is removed from "s"; after the second step, "p2" (matched by "p"), "a32&o" (matched by "[0-9]") and "apple" (matched by "p") are removed from "s".
The set "s" still contains two elements, "" and "fiddle". Validation therefore fails.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With