Re: [Json] JSON Schema Language

[Nico Williams <[e-mail]>]

On Mon, May 06, 2019 at 02:00:54PM -0700, Austin Wright wrote:
> > On May 6, 2019, at 12:24, Nico Williams <[e-mail]> wrote:
> > Because some of us have generic parsers with associated DSLs and we
> > don't want to be left out.
> 
> Left out of what, exactly? See below.

Out of interoperating with other applications using this schema thing.

> > [...]
> 
> I’m not suggesting a variance from the JSON semantics.

If you would have your parser reject 10.0 because the schema says to
expect an integer, then you are forking JSON as you are precluding
interoperability with some JSON encoders.  Especially too if you then
also insisted on a fractional part when a schema element expects a real
number so that you'd have the parser reject 10 -- then encoders would be
damned if they do and damned if they don't.

I explained how this would preclude use of jq or any other XSLT/XPath-
alike for JSON from interoperating with applications using such a schema
language.

> My suggestion is an alternative to parsers that lose data when they
> parse JSON documents, for example, ECMAScript's JSON.parse number
> parsing. You can, of course, always parse a JSON document according to
> the generic semantics.

The key word there is "alternative".  You're forking JSON.

> The issue here is how does a program parse a JSON document that with a
> wider range of values than what the program has room for? Either a
> string that’s too long, an array with too many items, or a number with
> too many significant figures?

I explained this earlier.

First, as to fractional parts of numeric values, a) zero fractional
parts MUST be tolerated, b) non-zero fractional parts can be truncated,
rounded, or rejected according to the schema authors' choice.

This is a case where being liberal in what you accept is a good thing.

> Normally you would have to write your own parser, or use a tokenizer

Why not use an off-the-shelf one?

> that preserves the lexical values without casting them to native
> types. Then you perform your own validation in code, and decide how to
> convert a lexical JSON number into a native number, depending on
> context.

That's one way, and it has to be possible, because that's essentially
what you'd do with jq or ECMAScript.

You could also use a streaming parser (which jq also has) to immediately
handle each value as it is parsed.

You could also write a combined parser and validator.

And, of course, you could generate a parser&validator from the schema.

I'm not rejecting any of those choices.

I'm insisting ONLY on the first choice (first parse, then validate)
needing to remain valid and workable.  If you make this choice no longer
feasible, then you've forked JSON.  Please don't.

Nico
--