Re: [Json] Interop problem report with number nasties

Carsten Bormann <cabo@tzi.org> Sun, 22 September 2013 07:31 UTC

Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAHBU6isWhqX=_cnfv+n2odkeFKjywH43nR9ASpKUwBWhq3qiLA@mail.gmail.com>
Date: Sun, 22 Sep 2013 09:30:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2589A1DC-2DF8-464A-B5B8-2A6312BAA184@tzi.org>
References: <CAHBU6isWhqX=_cnfv+n2odkeFKjywH43nR9ASpKUwBWhq3qiLA@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] Interop problem report with number nasties
Precedence: list

On Sep 22, 2013, at 01:09, Tim Bray <tbray@textuality.com> wrote:

> So encoding a -0.0 in JSON may lead to interoperability problems. 

As with the other number issues, it is not the encoding of a specific value by a sender that leads to an interoperability problem, but the sender relying on a specific interpretation of that value by the recipient.
Here, an interoperability problem would be caused if the sender relies on the recipient preserving the negativeness of the number, or on it differentiating it from a positive zero.

Say, if the required application semantics is that of a lookup table (alist), and a sender sends;

[[-2, "joe"],
 [-1, "jill"],
 [-0, "bob"],
 [0, "jack"],
 [1, "alice"],
 [2, "john"]]

Similar, a sender might rely on the recipient to preserve differences in encoding the same number, such as 0 vs. 0.0 vs. 0e0.  Example:

[[0, "joe"],
 [0.0, "jill"],
 [0.00, "bob"],
 [0e0, "jack"],
 [0e00, "alice"]]

Many programming languages make a strong distinction between NR1 (1) on one hand and NR2 (1.0) and NR3 (1e0) on the other hand.  Since the JSON spec says numbers look like they do in programming languages, inferring that there is a difference between them may be an excusable misinterpretation.  (I don't think anyone would justify relying on distinguishing 0e0 and 0e00, and only very few people would claim that 0.0 clearly differs from 0.00.)

I don't want to beat dead horses, but the interoperability issues come from us not defining the data model, but relying on implementers to pick it up from their background knowledge -- that background knowledge does differ in such details.

Example 2: 1 vs. 1.0.  https://jira.talendforge.org/browse/TDI-26517
is a random example of a bug report highlighting a data model problem.
The bug reporter expected the JSON library to make available to the
application a number as an Integer type independent of whether it was
notated sign-digits only (ISO 6093 "NR1", "integer") or has a decimal
point and/or an exponent (ISO 6093 "NR2/NR3", "real").  They were
rebuffed by the developer stating that JSON numbers notated as "real"s
can't be integers in the decoder's data model.  (Historically, most
programming languages have made such a distinction in number literals.
While RFC 4627 says, "The representation of numbers is similar to that
used in most programming languages.", this is expressly about the
representation, not the data model.)

Grüße, Carsten

PS.: Fun with just two implementations:

>> require 'json'
=> true
>> JSON.load('[-0]')
=> [0]
>> JSON.load('[-0.0]')
=> [-0.0]
>> require 'oj'
=> true
>> Oj.load('[-0]')
=> [0]
>> Oj.load('[-0.0]')
=> [-0.0]

But:

>> Oj.load('[-0e0]')
=> [0]
>> JSON.load('[-0e0]')
=> [-0.0]

So this is an example where
1) the apparent floatingpointness of the number influences the preservation of the negativeness
2) the interpretation of the floatingpointness differs between implementations.

[Json] Interop problem report with number nasties Tim Bray
Re: [Json] Interop problem report with number nas… John Cowan
Re: [Json] Interop problem report with number nas… Tim Bray
Re: [Json] Interop problem report with number nas… Carsten Bormann
Re: [Json] Interop problem report with number nas… John Cowan
[Json] Implementations that do not handle U+0000 Paul Hoffman
[Json] Dealing with -0.0 Paul Hoffman
[Json] Integer vs. floating point Paul Hoffman
Re: [Json] Dealing with -0.0 John Levine
Re: [Json] Integer vs. floating point John Cowan
Re: [Json] Integer vs. floating point Paul Hoffman
Re: [Json] Implementations that do not handle U+0… John Cowan
Re: [Json] Dealing with -0.0 Tim Bray
Re: [Json] Dealing with -0.0 Paul Hoffman
Re: [Json] Dealing with -0.0 Tim Bray
Re: [Json] Dealing with -0.0 John Cowan