What future compatibility means for the meta-schemas

[gregsdennis]

#1393 highlighted that there are differences of opinion on what future compability means for the meta-schema. This discussion will inform that one.

Two views have been presented:

1. An older copy of the meta-schema must be able to validate any schemas written today, even those that contain keywords that were added since the copy was "current." (You can use an older copy of the meta-schema to validate schemas with newer keywords.)
2. An older copy of the meta-schema only needs to be able to validate schemas which contain keywords that were defined when the copy was created. (You need a newer copy of the meta-schema to validate schemas with newer keywords.)

Note that this discussion is not about (although may inform) whether we "version" or "snapshot" the meta-schema for public consumption.

[gregsdennis]

I am in the (2) camp. We can't expect an old meta-schema to be tolerant of newer features.

(1) has significant problems:

• The meta-schema can't detect unknown keyword usage. It seems to me that this is something that we'd want considering the weight of that decision.
• The meta-schema can't detect misuse of future keywords. This absolutly causes breakages. (see below)
• Meta-schemas that are packaged with implementations will disagree with the implementation for schemas that use features that were added after the implementation package was created. (This is a bad developer experience.)

I think the second item here is the nail in the coffin for (1). If we have a meta-schema that allows future keywords without knowing the requirements of those future keywords, then I can write this schema today:

{
  "type": "object",
  "maxProperties": 10,
  "foo": 4
}

For all the meta-schema knows, foo is a future keyword, so it passes validation without error. (The implementation doesn't support foo, so the dev can't use it anyway, but let's focus on what the meta-schema says.)

However, in the future, we add foo, and it's value MUST be a string. Now the meta-schema fails validation saying that foo MUST be a string. This is a break. It's an incompatibility.

The only way to avoid this is to allow that an older copy of a meta-schema only validate those keywords which were defined when the copy was taken.

[gregsdennis]

Resolved here.