Re: [Json] JSON Schema Language

I was looking through the JSON specification and nowhere could I find a
reference to integers.  That indicates to me that any conversion from JSON
numbers to integers has to be done outside of JSON.  Conformant
implementations of JSON are thus free to do conversion from JSON numbers to
integers in whatever way they want.  There is a cost in doing the
conversion differently than common JSON implementations do, but that is a
different discussion.

I could, if I wanted, use JSON numbers to represent inexact numbers where
the precision of is +-1 in the last digit, so 4 is different from 4.0 is
different from 4.000000.  I have to be very careful that the only JSON
texts I allow are ones that are created with this understanding of numbers,
but I haven't done anything that violates the JSON specification.

Peter F. Patel-Schneider

On Tue, May 7, 2019 at 8:42 AM 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.
>
> Nico
> --
>
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json
>