draft7 schema incorrect in the definition of the "not" property?

[karenetheridge]

I suspect there is a bug in the definition of the 'not' property in https://json-schema.org/draft-07/schema# -- its definition is { "$ref": "#" }, i.e. the root document itself, but the document root also has "default": true defined. "not": true is false, so we get false! :o

Here's a simple example. I start with a schema {"type":"object"}, and seek to validate it against the draft7 spec while filling in missing values with their defaults. The resulting schema becomes:

{
   "additionalItems" : true,
   "additionalProperties" : true,
   "contains" : true,
   "definitions" : {},
   "else" : true,
   "if" : true,
   "items" : true,
   "not" : true,
   "patternProperties" : {},
   "properties" : {},
   "propertyNames" : true,
   "readOnly" : false,
   "required" : [],
   "then" : true,
   "type" : "object",
   "uniqueItems" : false
}

..And now, any data evaluated against this schema will fail, because of the "not": true section.

It is valid to evaluate defaults in the draft7 schema itself, isn't it? or am I missing something fundamental about how defaults should work?

[Julian]

Default "does" nothing, it's just informational, you don't fill in any values with it -- nothing in JSON schema mutates instances (or dictates their values).

[Julian]

(Similarly/relatedly -- the default value specified by default does not have to validate under the schema it's the default for)

[karenetheridge]

Interesting! looks like we need to remove a feature here then :) -- https://metacpan.org/pod/JSON::Validator#coerce

Admittedly the spec is not very verbose about how 'default' is intended to be used -- https://tools.ietf.org/html/draft-handrews-json-schema-validation-01#section-10.2

[karenetheridge]

Also https://json-schema.org/understanding-json-schema/reference/generic.html?highlight=default says "JSON processing tools may use this information to provide a default value for a missing key/value pair", suggesting the practice isn't too wacky :)

[awwright]

"default" isn't very intuitive in JSON Schema, because the schema is not going to be used unless there's a value that exists to use it. It's probably worth pointing this out more explicitly.

This is to say, "default" only applies once a value is created, it doesn't let you create missing properties or array items.

Once I decide to create a "not" property in a schema, that's when I could use the "default" value—in this case, the empty schema, i.e. true.

JSON processing tools may use this information to provide a default value for a missing key/value pair

Yeah this isn't consistent with how the rest of JSON Schema works. A better way to get this behavior would be to provide defaults for the object all at once:

{
  "default": {
    "port": 80
  },
  "properties": {
    "port": { "type":"integer" }
  }
}

This would be closer to the effect you're looking for.

I feel this still might not be quite right, though. Maybe we need a new keyword altogether, which means "if any of the listed properties are missing from the object, it will have the same behavior as the given value".

[handrews]

@karenetheridge Understanding JSON Schema was written independently and only recently moved under the JSON Schema org. It is an excellent resource in general, but has some, um... misunderstanding 😛 here and there, and we lack volunteers to either improve or replace it.

The not thing is definitely weird and I think we dropped it in draft 2019-09, but since default shouldn't automatically do anything, we probably just never got around to changing it.

You can offer a fill-in-defaults feature, but it should be on by.. er.. default 😄

[karenetheridge]

I think we can probably summarize this thread as "if you want to do anything with 'default', beware of dragons". :)

I'll look at what happened to 'not' in the latest draft, as I'm definitely making use of it here and there, e.g. implementing "you can have property 'a' or property 'b' defined, but not both" with {"not":{"required":["a","b"]}}.

[handrews]

@karenetheridge not behaves the same, but we formalized a lot of things about keyword behavior in the latest draft. Which hopefully would make it clear why default doesn't do things, it's just a value that's there (this is because it's a different class of keyword, an annotation, than something like type, which is an assertion, or not, which is an applicator).

[Relequestual]

@karenetheridge are we OK to close this? =] Feel free to shout if not / you have any other questions on this.

[karenetheridge]

Thanks for the clarifications.