Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@mooseyard.com designates
 208.97.132.66 as permitted sender)
Message-Id: <C69AD3E6-FB72-4906-86F4-59E643397824@mooseyard.com>
From: Jens Alfke <jens@mooseyard.com>
To: user@couchdb.apache.org
In-Reply-To: <B9C0BDBB-27A5-45C8-9CBF-A3506EB3FB13@gmail.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-72-614123416
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: Canonical JSON [Proposal for digital signatures of documents]
Date: Mon, 9 Mar 2009 10:22:41 -0700
References: <283A6EDD-6701-4A6A-88AE-8B97E6D11D9E@mooseyard.com>
 <B9C0BDBB-27A5-45C8-9CBF-A3506EB3FB13@gmail.com>

--Apple-Mail-72-614123416
Content-Type: text/plain;
	charset=WINDOWS-1252;
	format=flowed;
	delsp=yes
Content-Transfer-Encoding: quoted-printable


On Mar 8, 2009, at 4:51 PM, Antony Blakey wrote:

> OLPC has a start on canonical JSON: =
http://wiki.laptop.org/go/Canonical_JSON=20
> .

Thanks for the link! I'd done a bit of searching for prior-art, but =20
hadn't run across that.

It's pretty close to my description. It looks good, except that

=95 They say that arbitrary byte sequences are allowed in strings. This =20=

is really problematic (it makes it impossible to reliably convert JSON =20=

to an in-memory JavaScript string object!) and contradicts the JSON =20
spec, whose third paragraph says that "a string is a  sequence of zero =20=

or more Unicode characters".

=95 As I did, they say keys should be sorted in "lexicographic order". =20=

Like me, they probably meant "code-point order".

The ban on floating-point numbers is sensible. I'd draw the line at =20
banning integers, though, as that tends to really complicate round-=20
trip transformations with in-memory objects. (Every int field has to =20
be shadowed as a string.)

I've updated the wiki page accordingly.

=97Jens=

--Apple-Mail-72-614123416--