Should the stable release define a default dialect?

[jdesrosiers]

I think we're in agreement now [1] that we should have a stable URI that schema authors can use in $schema to indicate that they want the latest release of the stable dialect.

If that dialect URI never changes as we do more releases, it could make sense to declare that URI the default and lift the burden on schema authors to have to $schema in all of their schemas.

[jdesrosiers]

The risk with defining a default is that we can only do it once. If we ever need to change the stable URI, we couldn't make that the new default because given two schemas that don't declare a dialect, we can't know which default should apply.

The only way I would expect that this could be a problem is if we (in the distant future) decide to make significant changes and release a new version of JSON Schema. That new version would have a different stable URI and compatible releases would continue against that new stable dialect.

[gregsdennis]

Is having snapshot meta-schema URIs on-topic here? I believe this was a point of contention as well.

[jdesrosiers]

Only if you think it's relevant, but I don't see how. Setting a default only makes sense if there's a stable URI, which I'm not seeing anyone arguing against. I don't think it makes a difference to this discussion whether meta-schemas are released with unique URIs and the stable URI points to the latest, or meta-schemas are released with the stable URI.

[jdesrosiers]

Especially after the call today, I'm increasingly thinking it would be best to not declare a default now, but leave open the possibility of doing so in the future. We're trying out something new and we don't know exactly how it's going to work out. Let's give it a few years and see how things pan out. We can always declare a default later, but we once we have default, we can never change it.

[jdesrosiers]

I'm considering this the resolution and closing the discussion.

[SorinGFS]

Yes, I definitely agree that there should be a default URI for the latest release and that default URI should be default for those who do not specify another $schema in the files.

A schema is nothing more than a file that sits on a disk or is taken from the net. It's as harmless as a css file. In order for that file to take a role in a project, a user action is always necessary. When linking or including a schema or part of a schema in a project, the author can decide for himself to what extent the default URI is suitable for his project. The possibility of not specifying a schema will open the way to continuous integration both in projects and in implementations.

But, regarding the content of the default schema, I think it is the subject of another discussion.

At this moment, the schemas represent combinations of keywords. Schema v1 has, let's say, the keywords A B C, schema v2 has the keywords A B D, and the keyword A in v1 can mean something else than the keyword A in v2 (for example items). If for the future you promise to stabilize the meaning of keywords, then there could be a default schema that would be nothing more than the list of all keywords issued in the past without any constraints related to them. Those keywords can be considered a standard.

Then, another layer of abstraction should be introduced to provide direct access to meta keywords and to offer others the opportunity to create their own schemas that can then be referenced by projects. For example, implementations could have their own schemas for older drafts and at the same time a library that refers to the latest release. In this way, end users could be assured of a much easier transition to the latest release. In this way, over time the old schemas will disappear and the latest versions of all implementations will become compatible with each other.