Investigate CBOR compatibility

[awwright]

CBOR (RFC7049, http://cbor.io/) is considered a binary version of JSON, however it implements a superset of functionality, including native dates, byte (octet) strings (JSON is UTF), integers, URIs, and different storage formats for floating point and fixed and variable sized integers.

For draft-5, we need not add features specific to CBOR, but consider the ways that CBOR might be used, and make sure there's no definitions in outright opposition to this goal.

[yoshuawuyts]

This sounds reasonable.

[handrews]

As I understand it, there would be only a few things involved in basic "support" for CBOR

1. An application/schema+cbor media type
2. Declare that CBOR support at this point is limited to aspects of CBOR that are strictly compatible with JSON. Basically, a schema+cbor instance is just a schema+json instance re-encoded as CBOR.

It would be good to have even that very basic support in draft 05 so that people are encouraged to start playing with the concept.

The media type is particularly important to claim- if you're building a system that relies on standardized media types, you need one declared so that you can reasonably use it.

[epoberezkin]

I don't understand what is the value. If CBOR is only used just an alternative way to encode JSON, why does it need to be mentioned in spec in any way? Why not YAML then? Anything that maps to JSON can be used instead of it, why bother mentioning it in the spec?

[awwright]

YAML doesn't have a formal standard that we're able to reference - we'd have to reference the webpage, but I think if I picked one over another, CBOR has a well defined mapping to JSON, and it also demonstrates diversity a bit better because it's binary.

[epoberezkin]

@awwright you are missing the point. I was just using YAML as equally non-sensical example. Why include in the standard the things that have nothing to do with it?

[awwright]

As it relates to this issue, it helps avoid a monoculture -- JSON is a lot better than other media types for a lot of reasons, but other file formats might be better for different use cases.

Some might support comments, or be more human readable in general.
Some might be more compact or faster to parse, like a binary representation.
Some might be very more compact -- The EXI people have been in contact and interested in applying JSON Schema to JSON, where EXI is normally only used for XML.

So there's a variety of reasons you might want to support an alternate form of JSON-encodable data.

Why reference CBOR in particular? Because I think it's appropriate to issue an example that shows the breadth of what is supported, and CBOR is a standardized media type explicitly similar to JSON, that targets a different audience with a binary encoding.

[epoberezkin]

@awwright I completely understand the desire to use other formats to represent JSON data. I disagree with the need to include it in JSON schema spec. JSON schema is JSON data. Users can use any format they wish that maps to JSON. It's a much more general question that needs to be discussed in this spec. Why not keep it simple? Everybody seems to like simple ...

[epoberezkin]

To clarify: is there any aspect of using CBOR etc. to represent JSON schema that make it different from using it to represent any other JSON data? If there is, then it belongs to this spec. If there isn't, it would just litter the spec with trivial and general observations.

[handrews]

@epoberezkin I think the change is to indicate the applicability of JSON Schema to media types other than JSON by citing the closest related interesting media type rather than encoding JSON Schema in CBOR (which needs no explanation).

I work with/have worked with teams that are very sensitive to performance constraints. Most of the time when I get people to actually measure JSON "overhead", it turns out to be insignificant. But occasionally it is a significant factor, or the environment is so constrained that nearly any improvement is significant (which is basically what CBOR was designed for).

I generally try to push people towards CBOR rather than protobuf or other RPC-oriented serialization formats, and I usually have to show a lot of evidence of it as a broadly accepted media type for JSON-compatible binary environments.

So for me, the presence of CBOR in the JSON Schema spec strengthens my hand when making that case, so this change is on that I consider very valuable. And it's a tiny statement that costs us basically nothing.

[epoberezkin]

It increases the word count without changing anything. These applicability statements belong to separate publications rather than to the spec, because there are hundreds of other use cases and because they don't change anything from the spec perspective. But I'll leave this argument.