Subject: [Json] 2-step proposal 4627bis + I-JSON

From: Tim Bray <[email-masked]>
Date: Wed, 3 Jul 2013 16:46:04 -0700

I look forward to hearing what path Pete suggests through the thicket.
Here’s one that I think is plausible:

1. Do a 4267bis along the lines of the minimal-work proposals. It describes
JSON as she are spoke (wildly successful), changes as little as we possibly
can, documents the areas of interoperability breakage (dupes, surrogates,
top-level primitives), whacks the  regex in the security section, uses
SHOULD in the manner that Pete suggested is perfectly kosher. Declare
victory!

2. Recharter in a way that will allow us to produce something like a
strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html
Produce something like that. Second victory!

 -T

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Jul 2013 09:57:07 +1000

+1, although I'd strongly suggest that the top-level value NOT be a boolean, but instead an object; lots of people have talked about a top-level _"meta" object to hold information like profile identity, and if we're going to go to the trouble of defining something that intrudes into content, we might as well just do it once.

Cheers,

On 04/07/2013, at 9:46 AM, Tim Bray <[email-masked]> wrote:

> I look forward to hearing what path Pete suggests through the thicket.  Here’s one that I think is plausible:
> 
> 1. Do a 4267bis along the lines of the minimal-work proposals. It describes JSON as she are spoke (wildly successful), changes as little as we possibly can, documents the areas of interoperability breakage (dupes, surrogates, top-level primitives), whacks the  regex in the security section, uses SHOULD in the manner that Pete suggested is perfectly kosher. Declare victory!
> 
> 2. Recharter in a way that will allow us to produce something like a strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html  Produce something like that. Second victory!
> 
>  -T
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham   http://www.mnot.net/

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Jul 2013 19:00:31 -0500

On Wed, Jul 3, 2013 at 6:46 PM, Tim Bray <[email-masked]> wrote:
> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-json.html  Produce
> something like that. Second victory!

A hearty +1.

When I'm done with more pressing I-Ds (i.e., by Monday) I'll propose
text for (1).

Nico
--

---

From: R S <[email-masked]>
Date: Wed, 3 Jul 2013 17:18:43 -0700

+1

---

From: John Cowan <[email-masked]>
Date: Wed, 3 Jul 2013 20:27:32 -0400

> Produce something like that. Second victory!

This is a fine trial balloon.  I have two comments:

1) I do not understand the rationale of Section 2, which amounts to
saying that the top-level datum SHOULD NOT be an array.  The presence
of the string "urn:ietf:i-json" as the first element of the array would
serve the same purposes of self-identification, and an array (unlike an
object) will be serialized in order by any conformant serializer.  As for
extensibility, it is obvious that an array can be extended by adding
new elements to the end if the elements are semantically heterogeneous,
and if they are homogeneous, there is nothing to extend.

2) Stating the precision of numbers does not suffice: you ought also to
state explicitly that the valid range is numbers whose absolute value is
between 2^-1074 and (1 + (1 - 2^52)) * 2^1023, inclusive.  For example,
the integer 4503599627370497 is not exactly representable as a double (it
is 2^52+1) and ought not to be allowed in I-JSON.  So I still prefer my
proposal of "is exactly representable as an IEEE 754:2008 64-bit binary
floating point number".

-- 
A mosquito cried out in his pain,               John Cowan
"A chemist has poisoned my brain!"              http://www.ccil.org/~cowan
        The cause of his sorrow                 [email-masked]
        Was para-dichloro-
Diphenyltrichloroethane.                                (aka DDT)

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 4 Jul 2013 11:36:19 +1000

> Produce something like that. Second victory!

I-JSON has some great sections, but..

"urn:ietf:i-json":true  -- Ugh? Why? How do you think this would be used by apps receiving JSON? Do they switch between rejecting dups vs accepting last dup based on the presence of this element? Sounds unlikely.

"which MUST be the first member of the top-level object" -- please don't have this. It violates the rule that object elements are *unordered*, which just encourages more such violations.

We could claim victory if this spec encouraged most "common" JSON parsers to be modified so they could say they are I-JSON-compliant. That requires "common" parsers to switch to throwing an error when a dup is detected, instead of silently accepting the last value. I would love to see that, but I have seen no sign that this is likely.
 
--
James Manger

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 04 Jul 2013 13:07:15 +0900

> proposal of "is exactly representable as an IEEE 754:2008 64-bit binary

That doesn't work very well either, because you might need quite a few 
digits after the decimal point to *exactly* represent a binary fraction 
in decimal numbers. As an example, try to write something like
(2**52+1) / 2.0**200 (** being exponentiation)

You'll need something like 50+ digits, but nobody does this. What e.g. 
Ruby does (since about version 2.0) is to produce a representation that 
has just as many digits as necessary to unambiguously have a single 
closest representation in IEEE 754:2008.

Regards,   Martin.

---

From: Tim Bray <[email-masked]>
Date: Wed, 3 Jul 2013 21:25:04 -0700

Languages like Ruby and Lisp are pretty well proof against almost any
imaginable numeric representation.

But programmers in statically typed languages are going to do the
equivalent of org.json.JSONObject.getLong() or getDouble(), and the idea in
I-JSON is that if something in a JSON body is a number, it should Just
Work.  So I’m beginning to like John’s idea.  Although it might be
plausible to also say that if the number has no fractional part, it MUST
fall in the 64-bit integer value range.

But anyhow, this is premature.  Let’s hear some input from our chairs & ID
as to what the WG should be trying to produce. -T

On Wed, Jul 3, 2013 at 9:07 PM, "Martin J. Dürst" <[email-masked]>wrote:

>>> strawman I cooked up, I-JSON: https://www.tbray.org/tmp/i-**json.html<https://www.tbray.org/tmp/i-json.html>
> digits after the decimal point to *exactly* represent a binary fraction in
> decimal numbers. As an example, try to write something like
> Ruby does (since about version 2.0) is to produce a representation that has
> just as many digits as necessary to unambiguously have a single closest
> representation in IEEE 754:2008.
>
> Regards,   Martin.
>
> ______________________________**_________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/json<https://www.ietf.org/mailman/listinfo/json>
>

---

From: John Cowan <[email-masked]>
Date: Thu, 4 Jul 2013 01:48:58 -0400

"Martin J. Dürst" scripsit:

> You'll need something like 50+ digits, but nobody does this. What
> e.g. Ruby does (since about version 2.0) is to produce a
> representation that has just as many digits as necessary to
> unambiguously have a single closest representation in IEEE 754:2008.

Indeed.  The Scheme standard requires read/write invariance (what you write
is what you read, down to the last ulp) and the minimum number of digits
must be written.

-- 
I don't know half of you half as well           John Cowan
as I should like, and I like less than half     [email-masked]
of you half as well as you deserve.             http://www.ccil.org/~cowan
        --Bilbo

---

From: John Cowan <[email-masked]>
Date: Thu, 4 Jul 2013 01:50:24 -0400

> fall in the 64-bit integer value range.

For my taste that deviates too far from JSON's JavaScript roots, where
ther are no 64-bit ints, only doubles which are sometimes treated as
32-bit ints.

-- 
"Why yes, I'm ten percent Jewish on my manager's side."      John Cowan
    --Connie Francis                         http://www.ccil.org/~cowan

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 4 Jul 2013 13:09:09 +0100

Original Message From: "Manger, James H"
> To: "Tim Bray"

+1, while I'm here, but...

> "urn:ietf:i-json":true  -- Ugh? Why? How do you think this would be used 
> by apps receiving
> JSON? Do they switch between rejecting dups vs accepting last dup based on 
> the presence
> of this element? Sounds unlikely.

I too am a bit 'meh' on the self identification part.  (Knowing it's I-JSON 
is not even half way to knowing what you really want to know surely.)

Extending it to something like:

    "urn:ietf:i-json:jose" : true

or:

    "urn:ietf:i-json:com.codalogic:myprotocol:v2" : true

has some attraction though.  Although I think this would be more in the 
realms of convention than requirement.

Or an alternative syntax of:

    "urn:ietf:i-json" : "jose"
or:
    "urn:ietf:i-json" : "com.codalogic.myprotocol.v2"

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com