Subject: [Json] A schema language for JSON

From: Ulysse Carion <[email-masked]>
Date: Mon, 1 Apr 2019 20:06:33 -0700

Hi all,

Would folks in this list be interested in working on a schema language for JSON?

I am aware of JSON Schema <json-schema.org>, which has appeared in
this list before. But in my experience JSON Schema is not reliably
interoperable, perhaps as consequence of its complexity. The errors it
generates also leave something to be desired.

When writing data pipelines or simple JSON APIs (e.g. JSON-RPC), I
find myself wanting an interoperable schema language that I can
generate validators, classes/types, and fixtures from. It just needs
to be powerful enough to express structs, dictionaries, tagged unions
/ discriminators, and homogeneous arrays.

In the immediate, I ask if anyone would be interested in collaborating
on such a project, or helping to get it on the standards track.

I have written a tentative I-D for a JSON schema language. I am not
married to the proposals in the below I-D, but I do think they may
form a useful starting point.

https://github.com/simple-json-schema/simple-json-schema/blob/master/json-schema.md

Best regards,
Ulysse Carion

---

From: Pete Cordell <[email-masked]>
Date: Tue, 2 Apr 2019 12:04:22 +0100

A number of us have put together "JSON Content Rules" or "JCR".

The syntax of JCR is not JSON but is "JSON-like", possessing the 
conciseness and utility that has made JSON popular.

More details at:

http://json-content-rules.org/

Pete.
-- 
---------------------------------------------------------------------
Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
---------------------------------------------------------------------
On 02/04/2019 04:06, Ulysse Carion wrote:
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 2 Apr 2019 13:53:36 +0200

> Would folks in this list be interested in working on a schema language for JSON?

That depends a lot on what a “schema language for JSON” is for you.

Generally, this WG has been hesitant to adopt any specimen out of this loosely defined species, but has also been open to letting some flowers bloom.  Pete mentioned JCR, which is one of the more expressive proposals.

Over at the CBOR WG, we now have a specification approved for the “Concise Data Definition Language”, CDDL, which can describe CBOR data items, and, since the JSON data model is a subset of that of CBOR, JSON data items as well.  This has been used to define a number of JSON protocols, e.g., RFC 8007 and RFC 8428 (*).  It is not using JSON as its presentation language, but is more concise (**).  Since I don’t know your requirements, I’m not sure whether CDDL would be useful for you.  Please see https://tools.ietf.org/html/draft-ietf-cbor-cddl — currently in the RFC editor queue.

Grüße, Carsten

(*) Full list:
https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/referencedby/
https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/referencedby/
(**) An old comparison between what was then a version of “JSON Schema” (Gallege/Zyp/Court branch) and CDDL:
https://www.iab.org/wp-content/IAB-uploads/2016/03/Noise-in-specifications-hurts.pdf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Apr 2019 08:28:41 -0400

I have a schema tool as well. But it is more focused on the data model of
the source data than that of the JSON, XML, ASN.1 or TLS serialization.

The main use I make of the ProtoGen tool is actually generating
documentation rather than the code. The schema language includes slots for
the description to put in the reference manual. It is very much in the
DEC/VMS style of tooling:

http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html

Using ProtoGen, I can generate documents where the reference material and
the code examples are all generated from a single source. Which means that
when you see an example in one of my specs, that comes from running code
that was generated from the same source as the reference section.

XML Schema has a lot of features that turn out to be precisely useless for
exchange of data between network objects. And a lot of the same nonsense is
carried over into attempts to create JSON schemas.

For example, lots of schema proposals have the ability to restrict integers
to a range of values. I have used programing languages that have that type
of restriction but none of them is widely used for programming. If the
features are not widely used for coding the applications, they are not
required for a schema language either.

Same with the number of entries in a list. I have found that more than 95%
of the time, the only values for the minimum number of entries are 0 and 1
and the only useful values for the maximum number of entries are 1 and
infinity.

The data objects on either end of a communication can make use of complex,
rich data structures like sets, dictionaries, etc. etc. But the
serialization of all these encodings is the same, they all map to lists of
entries. So a protocol schema language is not the same thing as an
application program schema language.

My Protogen tool is available on GitHub but if we were to go for a
standardization effort, I would consider it an input rather than the
intended final product because as I said, it is not the only schema
language I have. Right now I have about 5 and I would like to collapse
these to 1 so that I can design a protocol without considering the encoding.

The Mesh is mostly in JSON but backwards compatibility requires code that
serializes/deserializes DNS protocol, TLS protocol, ASN.1, XML and of
course RFC822/821 style interactions. All this code is generated using
synthesizers. Right now, the reference code is all in C# but I am fully
aware that I need C/C++ libraries for deployment. My deployment strategy is
to retarget the code synthesizers to produce the different language(s).

As far as I am concerned, ASN.1 schema and XML schema are outputs from my
schema tools, not inputs.

So for example, I am currently looking at implementing Calendar and vCard
functionality. While I want to have all information available in JSON form,
I have to be able to import and export in the legacy formats. Unfortunately
the legacy encodings are not regular or consistent. So I write a schema
language that allows the idiosyncrasies to be encoded as hints.