Re: [Json] FYI ECMA, W3C, IETF coordination on JSON

Tatu Saloranta <> Tue, 08 October 2013 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2B3A11E8110 for <>; Tue, 8 Oct 2013 13:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PRcW85Igs8yo for <>; Tue, 8 Oct 2013 13:02:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::235]) by (Postfix) with ESMTP id 3CC4911E80F5 for <>; Tue, 8 Oct 2013 13:02:05 -0700 (PDT)
Received: by with SMTP id t60so3819425wes.26 for <>; Tue, 08 Oct 2013 13:02:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8ugn35lf9DSZhEnoLs+hKaYj9Ugy9pdtQq6ln/XjTxo=; b=dbHwD8bS1EVgSMBqTErT0yJgtoBOAIILcP9us2mAU8dIdvnp6qnlBTcLx6W1B3l2+h Mzi66hy5ysxkMc1stUU4zh4yP1FilPp1a281yV+56hvI1xlHYD4Gf1wcstz9Z4RJGQKh JmC/8BpmFKRZN3yRyzOgvlBe0VdpD9qqXmFRD6WZP/faslnBDr3mU6C+c3dqMv7jnRpy /lSFUNbPdTQ8+j1fdPoxQ/WajcE8PxE08N/f2/ZHu0JLqpPS/EL/nxFMppmZTqLOjE74 fvCmvF/aO9xm3eG9OQnEX3gV+cwqgF3ihik60zqeF3Ymlb5xXC5f+wmZnep8P5nGHTdc BEeA==
MIME-Version: 1.0
X-Received: by with SMTP id ca16mr3086750wib.57.1381262524411; Tue, 08 Oct 2013 13:02:04 -0700 (PDT)
Received: by with HTTP; Tue, 8 Oct 2013 13:02:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Tue, 08 Oct 2013 13:02:04 -0700
Message-ID: <>
From: Tatu Saloranta <>
To: "Peter F. Patel-Schneider" <>
Content-Type: multipart/alternative; boundary="f46d043c08101bfcd704e8403ecb"
Cc: Allen Wirfs-Brock <>, John Cowan <>, Larry Masinter <>, Brian Kardell <>, Tim Bray <>, JSON WG <>, "" <>
Subject: Re: [Json] FYI ECMA, W3C, IETF coordination on JSON
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Oct 2013 20:02:09 -0000

On Tue, Oct 8, 2013 at 12:48 PM, Peter F. Patel-Schneider <> wrote:

> I had first thought that JSON was really really interoperable.  Then I saw
> all the problems JSON-LD had with JSON.  Then I looked closer and saw

Could you elaborate bit on what kinds of problems there are?

the problems in JSON with numbers, and strings, and arrays. Then I said to
> myself "There really is no problem - although the syntax of JSON is too
> loose, and the description is too loose, everyone interprets JSON as if it
> was transmitting ECMAScript values."  Then I realized that this is not the
> case, and, moreover, that even ECMAScript JSON doesn't match the intuitive
> description of JSON.
> So I would say that JSON is only interoperable if you don't care too much
> about interoperability, and you don't hit any of the really ugly corner
> cases.
So why then is JSON so successful?  Well, it's easy to write, easy to read,
> matches programming language data fairly closely, and either you are both
> producer and consumer or you don't care that your system works correctly
> all the time so you don't care that JSON does not support interoperability.
I keep hearing all the claims of non-interoperability, but have seen barely
any problems that are actually on JSON data format level.
Almost only one I have seen is the limited numeric range of Javascript wrt
64-bit integers being one of few that has ACTUALLY surfaced.
This based on my 5 years of working on one of most widely used Java JSON
libraries, interacting on mailing lists.
Even discussion on potential issues (such as other concerns regarding
number representation) has been very limited.

Actual problems that are reported for interoperability are almost all
related to higher-level incompatibility: how are Dates translated into JSON
(numeric timestamp or String? Which of ISO-8601 variants?); whether it is a
good idea to translate simple structs into more elaborate ones with
metadata and so on.
But while these are real problems in context of systems that use JSON, none
of these issues is part of JSON the Format specification
In short, I think that these concerns are used in wrong context -- nothing
within syntactic definition, or semantics of simple values JSON has, will
help with these (valid) concerns.

Unless there is some effort to actually quantify ACTUAL syntax-level
interoperability problems encountered, it would be best to consider these
alleged or potential issues. They are not at "well-known fact" level
(except when used ironically to indicate that it's all hear-say & urban

-+ Tatu +-

> peter
> On 10/08/2013 12:21 PM, Brian Kardell wrote:
> [...]
>> So I guess my big question I keep asking myself is this:  Despite the
>> fact that it didn't involve standards bodies and committees to get out the
>> door - JSON is really *really* interoperable.  There are potentially some
>> edge cases, but given its importance to the Web it does seem like the ECMA
>> version is the most important baseline here.  If we want to make
>> improvements, why not just invent some other thing - not JSON... Call it
>> "super json" or "phil" or - just something else...And let that something
>> else attempt to address perceived problems and make some minor comments
>> about the ability to parse a subset of it with the standard JSON parsers
>> that conform to ECMA-404 or something and then go out there and compete and
>> see if it actually does better.  Maybe it will and we can all go have beers
>> and laugh about it, but - maybe it won't and at least we don't have to
>> break things.
>> --
>> Brian Kardell :: @briankardell
> ______________________________**_________________
> json mailing list