Update spec requirements around using a default dialect

[gregsdennis]

Implementations need to use the standard validation dialect when none is specified by the schema.

[gregsdennis]

Should we leave/add provision for an implementation to offer a configuration option for a fallback dialect (which defaults to the standard validation dialect)?

[jdesrosiers]

Yes. I expect that the dialect can be declared in multiple ways. The $schema keyword is one way, a media type parameter might be another, and a configuration option is yet another. The default should only kick in if there is no dialect declared in some way. How it's declared isn't important.

[gregsdennis]

As far as the configuration option is concerned, I would expect it to not override anything that's in a schema.

[jdesrosiers]

Right, I was expecting the question of how a dialect can be declared as a separate topic, but I don't think it had an entry in my original todo list.

I expect that $schema has highest precedence, then media type parameter, then configuration.

[gregsdennis]

... if media type parameter exists. My implementation doesn't consider media types; it deals with only content, irrespective of where that content comes from.

[handrews]

@gregsdennis typically this would be handled by a normative requirement to accept a meta-schema URI from an external source, rather than requiring the JSON Schema implementation to be media-type aware. Some other piece of software would parse the media type and then hand off the schema and the URI from the schema media type parameter to the JSON Schema implementation.

[jdesrosiers]

... if media type parameter exists. My implementation doesn't consider media types

Media types only come into play if you retrieve a schema over HTTP. Otherwise, media types and media type parameters don't apply. If you do fetch over HTTP and you are ignoring the content type of the response, I'd consider that a problem. However, although most implementations I've worked with support fetching over HTTP, very few handle media types properly.

Some other piece of software would parse the media type and then hand off the schema and the URI from the schema media type parameter to the JSON Schema implementation.

That only works for the root schema. If the implementation allows fetching references over HTTP, the fetching mechanism and media type awareness need to be built into the implementation.

[handrews]

Reference fetching is often a plug-in architecture, and it's more that the plug-in interface needs to accept the media type (which can indeed exist in systems other than HTTP). The HTTP plugin will of course handle the media type, and if you bundle that into the implementation then, yeah, there's "implementation code" for it, but we should keep in mind that even if there is not a true plugin system, implementations aren't monoliths. The requirements for loading and processing schemas need not be conflated with requirements for retrieving remote resources.

[jdesrosiers]

It was decided that we are going to put off having a default dialect for now, so I'm replacing this with #1420