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: jshttp/mime-db#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.

[Dragon-Seeker]

Any update about making this a reality?

[jdesrosiers]

There's no change in the status of this issue for now. Here's what needs to happen.

1. Release a new version of the spec
2. Register the media type with IANA
3. Get the new extension(s) added to mime-db
4. Hope that any tooling will understand the compound extension, but they probably won't.

We were blocked on step one for a long time for reasons I won't get into, but we're unblocked now and we're expecting to have that done this year. After that, the registration process can take as much as six months.

So, we're still working on it, but it's going to be a while, and even then it probably won't be usable in most tooling.