Re: [Json] JSON Schema Language

[Nico Williams <[e-mail]>]

On Tue, May 07, 2019 at 04:57:01PM -0700, Ulysse Carion wrote:
> 1. Considerable ink has been spilled on the question of integers in a
> schema language. The main question has been how such an integral
> constraint should relate to serialization.
> 
> 2. Some have raised questions around the terseness of JSON Schema and
> JSON Schema Language. Proposed alternatives are JCR and CDDL, by their
> respective editors.
> 
> On the first question, I would agree with Messrs. Bormann and Bray,
> who both suggest that a generic JSON parser runs first, followed by a

It's not that "a generic JSON parser runs first, followed by ...", but
that that must be a valid implementation choice.

> second pass over the data to convert the parsed data in the context of
> a schema. On such a view, "3" and "3.0" are typically
> indistinguishable by the time the schema is taken into account.

Correct.

> Bormann aptly notes that the alternative runs the risk of de facto
> forking JSON itself. I don't think there is much more to be said on
> the matter.

Excellent.  I think that's been put to bed now.

> The second question is perhaps more interesting, although it has
> provoked less discussion. I went with JSON as the representation
> because it makes building tooling atop of JSON Schema Language much
> easier, since it doesn't require that the implementor write a parser.

+1

I've been meaning for some time now to create an ASN.1 -> JSON schema
converter.  The idea would be to then use JS or jq to perform additional
analysis / modifications, and generate code.  In particular I'm looking
to express code generation controls using path-like expressions and thus
avoid having to express such controls as commentary or other
modifications to an ASN.1 module.

A similar approach using XML would also work, but then the right tool
would be XSLT/XPath, and I'm not too keen on that, having written a
not-too-trivial XSLT app.

> Such ease of extension is valuable: JSON is widespread largely because
> of how easy it is to build atop of, and we should not readily
> sacrifice this. JSON as the representation also unlocks syntax
> highlighting, formatting, and other such niceties for free.

JSON is a bit awful, honestly, but yes, it has these properties: that is
widely used, somewhat readable and editable, and has a lot of tooling
available.

> Furthermore, and most importantly, using JSON as a representation does
> not preclude later creating a RELAX NG-style compact representation
> later on.
> 
> I would also like to echo Bray's point about the real-world utility of
> such a system. My day-job involves APIs, event-sourcing, and analytics
> messages. In all three, JSON is the lingua franca, and in all three
> considerable tedium is involved in writing and maintaining validators
> and language-idiomatic containers for JSON messages. No
> language-portable solution to this problem exists today, short of
> moving away from JSON toward something like Protobufs or CBOR.

CBOR and other binary JSON formats have the benefit of keeping the data
model, which means that existing tooling can easily be made to interface
with them.

> I'd like to return to the initial question of this thread, this time
> rephrased:
> 
> Are we in agreement that the question of describing JSON, and from
> that description generating validators and idiomatic
> classes/types/etc, is a problem worth solving?

Of course it is.

> Are we in agreement that something along the lines of the proposed I-D
> may be a way we address this problem?

I shall have to read it.

Nico
--