Re: [Json] JSON Schema Language

> On May 7, 2019, at 08:42, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Tue, May 07, 2019 at 06:44:49AM +0200, Anders Rundgren wrote:
>> On 2019-05-07 00:38, Tim Bray wrote:
>>> I mostly fail to understand the debate about jq and integers and so
>>> on. Clearly, the following is a valid JSON text and will be parsed
>>> successfully by any JSON parser.
>>> 
>>> {
>>>   "foo": 3.0
>>> }
>>> 
>>> I imagine that most schema-driven software would first deserialize
>>> it into a tree, probably something like Jackson ObjectMapper's
>>> JsonNode, and then apply schema constructs to the tree.   I would
>>> hope that a sane schema would accept this whether a top-level "foo"
>>> was required to be an integer or double or most other flavors of
>>> number, and reject it if "foo" was required to be a string or
>>> boolean.
>> 
>> Here we have a little problem.  There are already quite popular
>> parsers out there flagging 3.0 as an invalid integer when explicitly
>> parsing for an integer[*].  Personally, I consider this as right thing
>> to do in a schema as well.  Letting one or two rotten eggs (=JSON
>> serializers that output Numbers that also represent exact integers
>> with fractions) set the bar for the other 99.9% doesn't seem right to
>> me.
> 
> Those parsers are broken.
> 
>>> Put another way, no JSON schema spec can change the definition of
>>> what JSON is, or make the built-in type system anything but what it
>>> is.
>> 
>> I don't think anybody is actually proposing that; only mapping things
>> that doesn't have a specific representation in JSON like integers.
> 
> Integers do have a specific representation in JSON, and anything that
> precludes generic encoders that might emit 10.0 where a peer parser will
> reject that as not-an-integer *is* a change to JSON.

I would put it slightly differently: While JSON doesn’t define any concept of an “integer”, applications that encode integers (e.g. uint32_t or similar) might conceivably emit it with the "frac” production (using a trailing decimal and zero); this is not ambiguous, and in the interest of being liberal in what you accept, parsers shouldn’t produce any error.

> 
> Nico
> -- 
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json