Paragraph regarding dated meta-schemas is more generic than unevaluated* and should be moved

[gregsdennis]

From section 11 of the core spec:

Updated vocabulary and meta-schema URIs MAY be published between specification drafts in order to correct errors. Implementations SHOULD consider URIs dated after this specification draft and before the next to indicate the same syntax and semantics as those listed here.

Seems like it's applicable to the draft as a whole and covers both spec docs.

[jdesrosiers]

It can just be removed because it's also stated in section 8.1.3.

Updated vocabulary and meta-schema URIs MAY be published between specification drafts in order to correct errors. Implementations SHOULD consider URIs dated after this specification draft and before the next to indicate the same syntax and semantics as those listed here.

However, that process seems problematic. The $schema keyword identifies both the version of the spec and location of the meta-schema. If we release a new meta-schema version, then there is no way to declare both draft 2020-12 and meta-schema 2021-04.

Unless that paragraph is suggesting that if I declare 2021-04, an implementation should assume 2020-12 because it's the closest version to 2021-04. Not only would that be an abuse of how URIs work, it would be very confusing for the community. When people start seeing $schemas with 2021-04, it's ambiguous whether a new draft came out or a bug was fixed in the meta-schema.

I think our only choices if we need to update any meta-schemas is either to release a new draft or make the changes and keep the same $id. As distasteful as both of those options are, I think that's the best we can do. I think the best experience for schema authors is to fix bugs without changing URIs and any changes that aren't critical can wait for the next draft. Or, we can come up with a way to declare the dialect independent of declaring the meta-schema, but I think that's unnecessarily complicated and a bad experience for schema authors.

[gregsdennis]

The $schema keyword identifies both the version of the spec and location of the meta-schema.

URIs for $schema and $id are just identifiers. There's no guarantee that the files exist at the identified location. Section 8.1.1:

If this URI identifies a retrievable resource, that resource SHOULD be of media type "application/schema+json".

But yes, revisions do present a URI connundrum.

[karenetheridge]

I think our only choices if we need to update any meta-schemas is either to release a new draft or make the changes and keep the same $id.

Agreed. If we do release new revisions, I would add a "$comment" to each document indicating the date of the last revision, so consumers of these documents can be sure which revision they have and track when updates occur.

[jdesrosiers]

URIs for $schema and $id are just identifiers. There's no guarantee that the files exist at the identified location.

I wasn't suggesting otherwise.

[handrews]

That process has always been rather wobbly, as some people expect bug fixes in place and others object to any in-place fixes. There are strong feelings on both sides and the closest we've come to being able to accommodate both is restricting in-place changes to when the published meta-schema is outright broken to the point of being unusable.

Also, implementation behavior should be done based on vocabularies, which are currently identified by pure URIs (there's no machine-readable spec even if there is a resource located at the URI). Since there's no machine-readable file to break or have a bugfix, those URIs should not change unless the identified semantics change.

So really, behavior shouldn't switch based on the meta-schema URI anymore, that's more of a human-friendly shortcut so most schema authors don't have to think about the seven (or whatever it is) different vocabularies in use. That was part of the whole point of separating vocabulary and meta-schema: vocabulary URIs are more stable and actually determine behavior, while people should feel free to write their own meta-schemas for whatever reason, which mostly will not be specifically recognized by the implementation.

This is because meta-schemas are for syntax (which can be enforced by normal validation of the schema against the meta-schema) while behavior (including loading extension modules) is driven by vocabularies.

[jdesrosiers]

So really, behavior shouldn't switch based on the meta-schema URI anymore, that's more of a human-friendly shortcut so most schema authors don't have to think about the seven (or whatever it is) different vocabularies in use.

Good point. That completely invalidates my argument. Given that perspective, I don't see a problem with releasing new meta-schemas with some version identifier such as https://json-schema.org/draft/{draft}/schema/{version}. The original template https://json-schema.org/draft/{draft}/schema can be used to refer to the "latest" version for that draft. That might be a best of both worlds solution. If you want updates automatically, you can use the "latest" template. If you want to pin to a specific version you can use the "version" template.

[handrews]

So it sounds like we just need to remove the duplicates (there's actually yet another one)? I'll make a PR for just that. If we still need to discuss more changes that can continue, but no reason to wait for the obvious part.

[handrews]

I'm going to go ahead and close this as fixed by PR #1101. The larger discussion about meta-schema release process and how to sort out the meanings of the dates in the URI probably belong as a discussion in the community repo.