json5

[mcandre]

Hi,

Can we please get support for JSON5, so that we can benefit from modern comment toggling?

[jdesrosiers]

I have good news for you. The JSON Schema specification already allows you to write your schemas in any format you like! As long as it can be parsed into something that's JSON compatible, you're good to go. For example, a lot of people write their schemas in YAML. It's not called "JSON Schema" because you write your schemas in JSON. It's "JSON Schema" because it describes JSON. You're more than welcome to write your schemas in JSON5 (which is a better choice than YAML IMO).

I'm guessing the reason you're asking is because you're working with some tooling that requires a JSON document. You'll have to ask the tooling vendor for JSON5 support. The spec already allows for it.

[mcandre]

Indeed, Compiling JSON5, YAML, and even non-JSON supersets to JSON is possible.

However, I do not expect that all JSON Schema libraries support JSON5 as direct input when supplying schemas to validator functions.

That is something that JSON Schema could explicitly require, for both schemas and values. In the next draft standard release version.

Not doing so results in JONS5 being effectively unviable until then, due to the sheer number of current implementation gaps. By forcing support in a new version, we arrive at an era where comments and trailing and single quotes and other intuitive JavaScript syntax can become the norm instead of a snowflake outlier.

[gregsdennis]

@mcandre the point that @jdesrosiers is making is that JSON Schema isn't built on any particular serialization of JSON, but instead on the JSON data model: objects, arrays, and the primitive types. You can use literally any serialized format that can be represented in this data model.

As such, the format itself is outside of the scope of the specification, so requiring JSON5 support isn't really in our purview. Even when writing schemas in YAML, it's the responsibility of the user to get the data into the appropriate model.

For example, my .Net library (JsonSchema.Net) supports the JSON models natively. .Net does support some JSON5 parsing, like comments. But if someone wishes to use YAML, I've also created an extension on YamlDotNet (by someone else) to convert their YAML model into .Net's JSON model. This kind of support will be dependent on the implementer or other open source libraries (or you could write it).

The point is that such support is out of scope for the spec.

other intuitive JavaScript syntax

JSON Schema is language-agnostic. We don't favor any language features, but we do try to consider languages when thinking about ease of implementation.

[jdesrosiers]

I'm curious what kind of tooling/language you're using that you feel limited to strict JSON. Most tools don't even take a JSON document (text) directly. Usually, you parse the document and then pass it to the library or just write the schema directly in host language. For example, with my JavaScript implementation, you'd do something like this,

registerSchema({
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.com/string",
  "type": "string"
});
const result = validate("https://example.com/string", "foo");

If you edit your schema in JSON document, then you'd do something like,

const schemaJson = await readFile("./string.schema.json", "utf-8");
const schema = JSON.parse(schemaJson);
registerSchema(schema);
const result = await validate("https://example.com/string", "foo");

The difference between those two has nothing to do with JSON Schema. You could use a JSON5 parser just as easy as using a JSON parser.

It's not a common feature, but I also allow you to reference a schema from the file system. For example,

const result = await validate("./string.schema.json", "foo");

In that case, I only provide support for JSON out-of-the-box, but I have a plugin system that allows you to add support for whatever you like. Perhaps you're doing something like that, but the implementation you're using doesn't have a way to plugin support for other media types?

[mcandre]

$comment is far more onerous than //.

Having to insert middleware between all JSON interactions is onerous.

We could significantly improve the quality of life by specifying that all implementations support JSON5 in the next draft version.