W3C home > Mailing lists > Public > public-wot-ig@w3.org > February 2017

RE: JSON Schema verbosity

From: Kovatsch Matthias <kovatsch@inf.ethz.ch>
Date: Wed, 15 Feb 2017 09:23:11 +0000
To: Henry Andrews <henry@cloudflare.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <55877B3AFB359744BA0F2140E36F52B55784FB02@MBX210.d.ethz.ch>
Hi Henry

Thanks again for joining; I think that was very helpful!

Something that comes to my mind:

* Consider registration of CBOR Tags: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

This allows to use numeric identifiers instead of sting-based keywords. Making it more compact. A further step might be allocating numeric value identifiers for your enums.

I will also post this to the GitHub issue.


From: Henry Andrews [mailto:henry@cloudflare.com]
Sent: Friday, 10 February 2017 00:31
To: public-wot-ig@w3.org
Subject: JSON Schema verbosity

Hi folks,
  It was wonderful to meet many of you at the F2F this week!  For those who were not in attendance, I'm one of the authors of the forthcoming draft of JSON Schema.

  I wanted to follow up on the concerns over JSON Schema's verbosity.  I can think of a few ways in which it is verbose which call for various different solutions.  I'm not sure which are of primary concern to the group so here they are:

* JSON takes up too much space on the wire.

Encoding JSON Schemas as CBOR seems the ideal solution, and perhaps registering a schema+cbor media type as well as schema+json.  See also https://github..com/json-schema-org/json-schema-spec/issues/6<https://github.com/json-schema-org/json-schema-spec/issues/6> (although there's a bit of a digression taking up a lot of space in the comments, I'm afraid).

* JSON itself is verbose and, as a human, reading large JSON documents is annoying.

I tend to write and review schemas in YAML and then convert them to JSON as a build step of some sort.  YAML is close to JSON but significantly more compact.  Also, it supports comments :-)

* JSON Schema has verbose keywords like "additionalProperties"

It seems like perhaps a terse version that would, for instance, use "ap" in place of "additionalProperties" could help if this is a concern.  Although if we establish JSON Schema validation as a vocabulary that JSON-LD can pull in, JSON-LD can handle aliasing the terms to whatever makes sense for that document's authors.

* Describing nested structures in JSON Schema takes up a lot of space.

There is a "deepProperties"/"deepRequired" proposal that would help with this- I was initially not a fan of it but I'm warming to the idea.  Please feel free to comment on it:  https://github.com/json-schema-org/json-schema-spec/issues/203

Did I miss anything?  Any thoughts on these possible solutions?



·        Henry Andrews  |  Systems Engineer

1 888 99 FLARE  |  www.cloudflare.com<https://www..cloudflare.com/>
Received on Wednesday, 15 February 2017 09:23:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:10 UTC