Re: [Json] Adding integers to JSON (Re: JSON Schema Language)

[Nico Williams <[e-mail]>]

On Wed, May 08, 2019 at 09:30:36PM +0200, Carsten Bormann wrote:
> Hi Nico,
> 
> > On May 8, 2019, at 20:31, Nico Williams <[e-mail]> wrote:
> > 
> > On Wed, May 08, 2019 at 06:59:54PM +0200, Carsten Bormann wrote:
> >> On May 8, 2019, at 18:07, Nico Williams <[e-mail]> wrote:
> >>> That's an interop bug.  They should fix it.
> >> 
> >> It also nicely demonstrates the law of inevitable extensibility.
> >> 
> >> JSON was designed not to provide extensibility.  Ever.
> >> Radical, but a well motivated idea at the time.
> > 
> > The spec allows extensions, actually, but indeed, it doesn't provide for
> > extensibility.
> > 
> > (For example, jq will parse Inf and Infinity, but it will not output
> > such words, nor will it output NaN.)
> 
> Huh?  RFC 8259 is very outspoken here:
> 
>    Numeric values that cannot be represented in the grammar below (such
>    as Infinity and NaN) are not permitted.
> 
> So you have a superset of JSON as your jq input grammar, which is fine
> for me (it just isn’t JSON anymore).  Maybe you mean the sentence in
> the section about Parsers:
> 
>    A JSON parser MAY accept non-JSON forms or extensions.

Yes.

> Yep, non-JSON.  JSON has no extensibility points.

A JSON-like text with 'Infinity' in it is not-JSON.

> > The particular “extension" we're talking about isn't an extension.
> 
> Extending the data model to enable expressing two different kinds of
> numbers, which are identical in numeric value (i.e., JSON semantics),
> but have different semantics in the data model defined by the
> extension (distinguishing integer 3 from floating point 3), definitely
> is an extension.  The fact that only instances are communicated that
> are also valid under (by definition unextended) JSON semantics doesn’t
> change this.

Yes, but note that accepting 'Infinity' doesn't cause an
interoperability problem, while rejecting '3.0' does.

Nico
--