In the original issue #512 @handrews stated that $defs is actually more of a recommendation while definitions and basically any other arbitrary keys (see #512 (comment)) should continue to work, too.

• @about-code in the related issue

$defs is the recognised keyword, changed form definitions in previous draft-7.

Essentially, your question is, should definitions continue to work with draft-8?

The answer is, maybe, but you shouldn't rely on such, because the behaviour is now undefined.

Some implementations may choose to support referencing using arbitrary keys, but it's not required. There are lots of "super edge" cases that we would need to consider to define the behaviour, so rather than forbid it, leaving it undefined leaves implementations to document specific support for users who don't need their schemas to be portable. "behaviour is undefined" essentially translates to, "Probably not a good idea, as it's complex, but we won't stop you doing it if you really want, and understand it will likely mean your implementation isn't portable".

I hope that gives some additional clarification.

@Relequestual @about-code OK I actually did some serious-ish reworking.

I had come up with the idea of $defs and $comment as "reserved location" keywords, and forgot that I'd never actually put that in. So I added a fourth keyword category, which I think makes it obviously you can add more keywords like that. I'm not going to outright say "you can make a keyword exactly like $defs because we don't really want people to do that. But it should be clear that it's valid now.

@Relequestual definitions is actually sort of still reserved by the default meta-schema. I clarified that in the validation spec. The idea of calling that particular meta-schema the "default meta-schema" is part of #780.

I updated both $defs and $comment to use wording about reserving locations, which also avoids the question of how forceful "standard" is. Reserving a location does not imply that all other locations are unusable. It just implies that this location is reliably usable.

I think this is a good improvement overall, so thanks for bringing it to our attention, @about-code !

@Relequestual Some implementations may choose to support referencing using arbitrary keys, but it's not required.

For example, mine does this. It allows $ref to point anywhere, but if what it finds is not a schema, it throws an exception.

@gregsdennis also, presumably if you have a structure like:

{
 "$id": "https://this.example.com/schemas/foo",
 "$ref": "#/a/b/c",
 "a": {
 "b": {
 "$id": "https://that.example.com/schemas/bar",
 "c": {
 "$ref": "somewhere#/$defs/whatever"
 }
 }
 }
}

where a, b, and c are all unrecognized keywords and all of them take schemas as values, you will end up evaluating the $ref in c incorrectly because you did not take into account the $id in b.

Or if you're implementation does look at that $id, and if b in fact instead does not take a schema, but allows arbitrary keys which take schemas (like properties), then that would also produce the wrong $ref resolution behavior.

@gregsdennis @Relequestual , the point here isn't about implementations choosing to "support" arbitrary keys. The point is that it is absolutely not possible to guarantee the correct behavior of nested arbitrary unknown keys. There is no way to do it. You have to decide whether you look for $id in intervening levels, but since there are two possibilities and you can't implement both at once, you are guaranteed to produce the wrong behavior for one use case or the other.

This is a strange corner case, but it is critically important not to over-promise spec behavior.

You cannot do this correctly, and shouldn't claim to do so.

However, you can get away with (for lack of a better term) schema duck typing for a single level of unknown keyword, because it's not possible to insert an unexpected $id anywhere. But that's it. Claiming to match whatever assumptions people make beyond that is in violation of the spec. You can document a consistent behavior, but understand that there are cases where it will be wrong.

Yeah, hopefully people don't do that because it's really weird.

@gregsdennis

Yeah, hopefully people don't do that because it's really weird.

LOL have you met people? 😆

Are you OK with these changes as I've updated things?

OK, @about-code I made both of those places consistent by using "location-reserving keywords" and "reserves a location", respectively.

Since those changes are pretty trivial, and @Relequestual 's only specific change request was a comma that I fixed yesterday, I'm going to go ahead and merge. @Relequestual seemed to approve the changes aside from that grammar thing. And Greg approved yesterday.