Re: [Json] JSON Schema Language

[Nico Williams <[e-mail]>]

On Mon, May 06, 2019 at 10:55:56AM +0200, Anders Rundgren wrote:
> On 2019-05-06 09:22, Austin Wright wrote:
> <snip>
> > 
> > Can you elaborate on this? My point is primarily concerned with JSON
> > parsers, not JSON the media type.
> > 
> > Suppose a string were too large to store in memory, most ECMAScript
> > engines would bail with an uncatchable error. The suggestion is to
> > implement this more robustly, like throw an error if a string would
> > be too long, or if a number has too many significant figures;
> > instead of either crashing or silently approximating the number.

What's that got to do with schemas?

> I don't understand this.  A JSON schema is a description of a JSON
> document.  If the description is incompatible with implementations
> that are supposed to parse compliant documents all bets are off.

A schema is not a description of a document but a description of a class
of documents.

I suspect that you think the point of a schema is to allow you to have a
parser that parses straight into an internal representation specifically
derived from the schema, but that is not the only possibility!

It should absolutely be possible to first parse a JSON text with a
*generic* JSON parser, *then* check if the parsed thing meets the
requirements of the schema.  This is a very reasonable thing to do,
especially with general-purpose languages like ECMAScript, or jq that
deal with JSON very naturally.  I object strongly to any JSON schema
that makes this approach not workable.

> > But also, why not build a parser that uses a schema to influence how
> > values are parsed? Suppose you have a dynamically typed language,
> > and want to parse some value, e.g. sometimes as an int, sometimes as
> > a bignum, depending on the property. You might provide a JSON Schema
> > to specify this behavior.
> 
> This sounds like an edge-case but it could be supported by an "any"
> type (although don't particularly see how this could work in a
> cross-platform scenario).

Or a CHOICE.

(Here, again, I have to say that ASN.1 already has all these things, so
we should at least be informed by it before we go off and reinvent that
wheel badly.)

Nico
--