Description
At ietf-wg-httpapi/mediatypes#43, the JSON Schema section currently specifies that the specification document may change based on certain factors. This is done for reverse compatibility, however this is in contrast to the behavior used by JSON Schema implementations (where old drafts have been obsoleted), and Internet media types in general (where a single specification must specify all of the essential behavior).
Historically, backwards compatibility has been the responsibility of each implementation. (Since a schema often is only processed by a single validator, that validator has the best idea on how to do this.) Newer publications replace older ones in their entirety; and deprecated behavior was simply removed, leaving it up to individual implementations to choose what would work best, since the behavior is now undefined.
This is not workable when backwards-compatibility is expected cross-platform, as in an Internet media type. And implementing every publication of JSON Schema is not sustainable, and was never intentional (a meta-schema is not a strong version identifier, and we offer no guidance as to which versions you would have to implement, or how to handle unknown future versions).
Some older behavior that has been removed, we can re-define in a new "deprecated functionality" section. Behavior has been removed for a variety of reasons, sometimes implementations disagreed on what the behavior would be and removing it was easiest, so this section cannot guarantee compatibility with all older schemas. However, text-compatibility with older publications should be possible.
A list of things to support
Let's make a list of cases where standardization of some behavior was dropped ("deprecated" or "un-defined"), and where it was changed ("broken"). Let's make sure this behavior is written into the spec, and with the goal of eliminating any need to reference to older versions of JSON Schema Core.
Deprecated core behavior
Behavior that has no reason to change based on $schema:
$id: "#foo"
as an alias for$anchor: "foo"
"id"
as an alias for"$id"
Deprecated validation keyword behavior
Behavior that could hypothetically change based on the value of $schema:
- boolean forms of exclusiveMinimum, exclusiveMaximum
- schema values in "type"
Breakage:
Behavior where the same schema would be required to produce a different result depending on the release of JSON Schema being read:
- Keywords next to $ref changing from ignored to processed (this was deliberate and does not need to be supported: nobody was using validation keywords next to $ref expecting them to be ignored)
1.0
being an integer:type: "integer"
would previously validate false, now true (I'm unaware of any problems caused by this change in the wild: only a minority of implementations ever followed the older behavior, and of those, they rarely encoded1.0
where the datatype wasn't specifically known to be a floating point)