Define the `schema.json` file-extension for application/schema+json

[jdesrosiers]

https://github.com/jshttp/mime-db is a widely used database of media-type <=> file-extension mappings. Notably, mime-db is used by Github Pages. So, if we can add application/schema+json <=> schema.json, then any file with a schema.json extension will be served with an application/schema+json content-type.

Before we can add our mapping to mime-db, we need to document the schema.json file extension in the spec.

[jdesrosiers]

I opened an issue with them to ask some questions: https://github.com/jshttp/mime-db/issues/247.

Summary: I think they'll accept it if we add the extension to the spec, but that doesn't necessarily mean that anyone using mime-db will be able to correctly handle an extension with a . in it.

I'm thinking we register both schema.json and something else without a .. That way there's a fallback if schema.json doesn't work in some places.

[ericmorand]

@jdesrosiers,

I'm thinking we register both schema.json and something else without a .. That way there's a fallback if schema.json doesn't work in some places.

I agree with you: I think it is mandatory to propose an alternative to schema.json because most resolvers only rely on the last extension of a file to resolve its format. Even smart resolvers like TypeScript one will resolve a schema.json file as JSON even if a *.schema.json module is provided and resolveJsonModule is enabled.

So, definitely, a proper and unique extension should be proposed. Something like jsonschema.

[jdesrosiers]

It's a shame that many applications will likely choke on *.schema.json. With a pattern like this, applications that understand schema.json can treat a file like a schema, while applications that don't understand schema.json can still fall back to treating it like a json file instead of just having no idea at all.

[Relequestual]

I really don't want to create two classes of tools. We already have a huge "this tooling doens't support that part of the spec" issue.

I'm strongly in favour of *.schema.json. I don't know that tooling would choke, but most likely fall back.

What I don't want is a situation where someone maintains a set of JSON Schemas, and one tool they use understands .schema.json and another only understands .jsonschema, and therefore they cannot use both tools.

I feel like I understand the counter arguments, but I still feel like this is the better solution

Even if we were to go for .jsonschema, it wouldn't allow for fallback behaviour.