- From: Jorge Chamorro <jorge@jorgechamorro.com>
- Date: Tue, 8 Oct 2013 22:06:21 +0200
- To: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Cc: John Cowan <cowan@mercury.ccil.org>, Allen Wirfs-Brock <allen@wirfs-brock.com>, JSON WG <json@ietf.org>, Tim Bray <tbray@textuality.com>, "www-tag@w3.org" <www-tag@w3.org>, Larry Masinter <masinter@adobe.com>
On 08/10/2013, at 21:14, Peter F. Patel-Schneider wrote > On 10/08/2013 11:43 AM, Jorge Chamorro wrote: >> On 08/10/2013, at 20:26, Peter F. Patel-Schneider wrote: >> >>> The paragraph on numbers, see below, seems rather dangerous, as well as being incorrect. >> Is it? Why? >> > Well, for starters, interchanging non-integers can lead to loss of precision, which can be dangerous. Further, interchanging numbers without some notion of the limits of the receiver is also dangerous. > > Second, JSON does not only use sequences of digits to represent numbers, and there are many JSON numbers that cannot be represented as a sequence of base-ten digits. > > Third, there are many numbers that humans interchange that cannot be represented as finite sequences of digits, even if you allow also a decimal point and a negative sign, for example 1/7, pi, and the square root of two. (Perhaps the wording in the introduction is meant to allow infinite sequences of digits, but then using JSON for interchange is a bit difficult.) My understanding is that limiting the representation of numbers to something like the JSON syntax is more of a computer thing than a human thing. Ok, look: he's done -and very well- what he said should be done: Begin forwarded message: > From: Douglas Crockford <douglas@crockford.com> > Date: 13 de junio de 2013 17:50:33 GMT+02:00 > To: "json@ietf.org" <json@ietf.org> > Subject: [Json] Two Documents > content-type: text/plain; charset="us-ascii"; Format="flowed" > > The confusion and controversy around this work is due to a mistake that I > made in RFC 4627. The purpose of the RFC, which is clearly indicated > in the title, was to establish a MIME type. I also gave a description of > the JSON Data Interchange Format. My mistake was in conflating the two, > putting details about the MIME type into the description of the format. My > intention was to add clarity. That obviously was not the result. > > JSON is just a format. It describes a syntax of brackets and commas that > is useful in many contexts, profiles, and applications. JSON is agnostic > about all of that stuff. JSON shouldn't even care about character encoding. > Its only dependence on Unicode in the hex numbers used in the \u notation. > JSON can be encoded in ASCII or EBCDIC or even Hollerith codes. JSON can > be used in contexts where there is no character encoding at all, such as > paper documents and marble monuments. > > There are uses of JSON however in which such choices matter, and where > behavior needs to be attached to or derived from the syntax. That is > important stuff, and it belongs in different documents. Such documents > will place necessary restrictions on JSON's potential. No such document > can fit all applications, which causes much of the controversy we've seen > here. One size cannot fit all. JSON the format is universal. But real > applications require reasonable restrictions. > > So we should be working on at least two documents, which is something we have > discussed earlier. The first is The JSON Data Interchange Format, which is > a simple grammar. The second is a best practices document, which recommends > specific conventions of usage. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json ECMA-404 is simple, complete, easy to read and extremely clear: excellent. -- ( Jorge )();
Received on Tuesday, 8 October 2013 20:06:56 UTC