Re: [Json] JSON Schema Language

[Austin Wright <[e-mail]>]

> On May 6, 2019, at 14:15, Nico Williams <[e-mail]> wrote:
> 
> 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.

You’ll need to provide a specific example, I think there’s a misunderstanding.

> 
>>> [...]
>> 
>> 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.

I never suggested this. While JSON doesn’t specify what an “integer” is (i.e. we could define it to be any subset of number that we want), JSON Schema tries to be liberal and specifies that excessive precision still qualifies as an integer. (I’m the one who added that 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
> --