
ECMA-404: The JSON Data Interchange Format [pdf] - dphnx
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
======
jcampbell1
No thanks to Mr. Crawford for not fixing the \u2028-9 issue. JSON as defined
is _not_ a subset of javascript. It is a design mistake that was pointed out
to him _years_ ago, but he is too stubborn or arrogant to fix it.

~~~
baldfat
Why do you ask him without the stubborn and arrogant comment on G+ and about
trailing commas? Or is indirect better?

~~~
jcampbell1
Trailing commas would make the problem worse! If you allow trailing commas
then you would break json parsing in all old version of IE. The unicode line
ending problem is more subtle.

I have seen people write code like (mix javascript and some templating):

    
    
        <script>
        var prefs = <%= user_prefs.to_spec_conforming_json() %>;
        ...
    

The above code looks okay, but if the json is just spec conforming, then you
are exposed to a potential XSS attack.

Most people that write json encoders are aware of the problem, but why publish
a a spec that can potentially create serious security problems?

~~~
ante_annum
> you would break json parsing in all old version of IE

Why do people still care about old versions of IE?

~~~
drhayes9
~22% of China still uses IE6:
[http://www.ie6countdown.com/](http://www.ie6countdown.com/)

Developing nations have a tendency to not use the latest and greatest. If
reaching them is important for you/your product then you have to keep tracking
this stuff.

~~~
zanny
> Developing nations have a tendency to not use the latest and greatest.

Attention developing nations: Chromium and Firefox are completely foss. No
excuse, unless you don't have an internet connection.

In which case, what do you need a web browser for?

~~~
jwdunne
I'm not sure about this but a lot of software might have been written
specifically for IE6 and IE6 only, which might not translate well to
Chrome/Firefox, and could cost businesses a lot of money, more money than they
deem its worth. There could be ActiveX controls and such which can't be ported
to Chrome/Firefox without money.

This is based on my experience at UPS which used a single machine using IE6
and some form of web app to control start up and shut down procedures, or
something to that effect. It had no Internet connection, only LAN I believe.

I did ask myself this question too and it does seem peculiar. After some
thought, my only guess is the above!

~~~
jlgreco
Don't they have another browser around for dealing with the rest of the world
though? It's not like many modern sites are going to render correctly on IE6
these days...

~~~
eropple
But all _their_ apps work with IE6, and who cares about people trying to view
Facebook while working?

~~~
jlgreco
If they are off in their own totally isolated little IE6 only world, I don't
get why we care about them then.

~~~
eropple
Because their workers _do_ go view Facebook. If that's a market you need to
target, you need to make it work with IE6.

(There's also the whole "they get infected with everything under the sun and
make the rest of us deal with them", but that's not a visual issue.)

------
Stratoscope
Several comments mention the "Software shall be used for Good, not Evil"
licensing issue in the JSON code from json.org.

The original json.js file from json.org had this copyright and license:

    
    
      Copyright (c) 2005 JSON.org
      
      Permission is hereby granted, free of charge, to any person obtaining a copy
      of this software and associated documentation files (the "Software"), to deal
      in the Software without restriction, including without limitation the rights
      to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
      copies of the Software, and to permit persons to whom the Software is
      furnished to do so, subject to the following conditions:
      
      The Software shall be used for Good, not Evil.
      
      THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
      IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
      FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
      AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
      LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
      OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
      SOFTWARE.
    

[http://web.archive.org/web/20060226161035/http://www.json.or...](http://web.archive.org/web/20060226161035/http://www.json.org/json.js)

This was a standard MIT license with one change:

"This license uses the Expat [MIT] license as a base, but adds a clause
mandating: “The Software shall be used for Good, not Evil.” This is a
restriction on usage and thus conflicts with freedom 0. The restriction might
be unenforcible [sic], but we cannot presume that. Thus, the license is
nonfree."

[http://www.gnu.org/licenses/license-
list.html#JSON](http://www.gnu.org/licenses/license-list.html#JSON)

However, the current versions of json.js and json2.js on GitHub contain only
this public domain dedication and disclaimer:

    
    
      Public Domain.
    
      NO WARRANTY EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK.
    

[https://github.com/douglascrockford/JSON-
js/blob/master/json...](https://github.com/douglascrockford/JSON-
js/blob/master/json2.js)

So it's no longer an issue. You can feel free to use json2.js for good _or_
evil.

~~~
jmulho
That's great news. It has been a major inconvenience to remember to use XML in
all of my evil applications.

~~~
alexhawdon
I switched a few of mine to JSON but the clients complained that this
undermined the final deliverable. I was forced to switch back.

------
curveship
I really (really really) wish they'd added a way to represent dates. Dates
were left out of the original JSON spec since javascript doesn't define a
syntax for date literals. You have to execute the Date() constructor to make
them. Since JSON was supposed to be a subset of _non-executing_ javascript,
dates were excluded from JSON.

That left serialization to a string as the only way to transfer dates. But
since there's no specification for the format to use, cross-browser date
parsing is a mess (see [http://dygraphs.com/date-
formats.html](http://dygraphs.com/date-formats.html) ). JSON + dates =
sadness.

The non-executing constraint on JSON was a good idea in its early days, when
eval was the most common way to parse JSON, but now that there are dedicated
parsers for all environments, it's not as much a priority. But we're still
stuck with kludgy workarounds for the lack of native date support in JSON.

If there's still concern about using the Date constructor, the spec could
require that the date be prefixed to avoid execution: "0 || new Date(...)".
Real parsers would extract the date correctly, eval would just return 0.

~~~
TazeTSchnitzel
>But since there's no specification for the format to use, cross-browser date
parsing is a mess

Wrong! Since ECMAScript 5 there is a single, standard format that all browsers
will try to parse first and can predictably output: ISO 8601.

    
    
      --
      [02:49:29.621] (new Date()).toISOString()
      [02:49:29.623] "2013-10-12T01:49:29.623Z"
      --
      [02:49:40.233] JSON.stringify(new Date())
      [02:49:40.245] ""2013-10-12T01:49:40.246Z""

~~~
curveship
No, not all browsers, and not all of ISO 8601. Safari only added ISO 8601 Zulu
parsing in the last few months, and IE only at version 9. Neither support
explicit timezones yet. Which means there's still a large population of
browsers that will choke. As I said, date parsing is a mess.

In any case, my general point still stands: dates are the only "data" type
(i.e. not a function, regex, etc.) which is not supported by JSON. So even if
there were a usable universal serialization format, you'd still need to post-
process the results of the JSON parser to convert the strings into dates.

------
consultutah
Hilarious! ECMA-404. My neighbor's address is 404 West Whatever Street and I
can't look at their mailbox without wondering if mail is correctly delivered
there...

~~~
danabramov
... Or if maybe they're getting everyone else's misattributed mail.

------
Jare
My faint hopes for trailing comma support are now crushed.

~~~
rpedela
What does trailing comma support get you?

~~~
swift
It simplifies generating JSON, since you don't need a special case for the
last item, and it simplifies editing it, since you don't need to do something
special when adding a new item at the end. I can't see any benefit to _not_
having it, honestly.

~~~
mercurial
> It simplifies generating JSON, since you don't need a special case for the
> last item

In which language can't you do array.join(",")? You can even do that in Java
with one of the myriad of string libraries. I haven't hand-coded joins since
(at least) six or seven years.

~~~
lttlrck
Join doesn't help to stream to JSON from a database cursor. Unless you buffer
the response first which is pretty horrid.

~~~
mercurial
Fair point.

------
basicallydan
Great stuff. On a side note, this ECMA website is fantastic. I've never seen
it before, but it's really quite interesting to change the URL to random
numbers to find out what other standards ECMA has done.

For instance, there's a standard for measuring computer equipment in
controlled rooms: [http://www.ecma-international.org/publications/files/ECMA-
ST...](http://www.ecma-international.org/publications/files/ECMA-
ST/Ecma-160.pdf)

And here's an important one, DVD-RAM discs: [http://www.ecma-
international.org/publications/files/ECMA-ST...](http://www.ecma-
international.org/publications/files/ECMA-ST/Ecma-330.pdf) and their cases:
[http://www.ecma-international.org/publications/files/ECMA-
ST...](http://www.ecma-international.org/publications/files/ECMA-
ST/Ecma-331.pdf)

Plus, NFC: [http://www.ecma-international.org/publications/files/ECMA-
ST...](http://www.ecma-international.org/publications/files/ECMA-
ST/Ecma-340.pdf)

It's all new to me!

------
JulianMorrison
Where this might be important: governments and bureaucracies which have a
fondness for formally specified standards. Now they can adopt JSON.

------
Touche
Does this mean we can now use it for evil?

~~~
oneeyedpigeon
No, only for eval ;-)

------
seanconaty
What's so awesome about JSON? Its standard documentation is 5 pages. So
simple, so awesome.

~~~
fleetfox
It's not XML

~~~
tel
XML has its time and place. I'm currently doing medical data processing and
I'm really glad it's XML instead of JSON.

------
oneeyedpigeon
Why can the solidus (/) be escaped?

~~~
oneeyedpigeon
Oh, god - apparently, it's to support IE5.5 and to allow "</script>" to be
embedded in a "<script></script>" pair and not be interpreted as closing the
script. I wish I hadn't asked, and I wish I hadn't then gone and found out ...

~~~
alternize
thanks. was wondering the same...

------
minor_nitwit
Excellent standard: Contains not a single example of what actual JSON looks
like in text.

------
penguindev
"So for example, a string containing only the G clef character (U+1D11E) may
be represented as "\uD834\uDD1E""

eww, UTF-16 surrogate pairs. Die, die, die, you scourge. (Yes, I've been
working with the win32 api lately, which was designed for UCS2/UTF-16).

when has 16 bit anything been a good idea, really. TCP port ranges, looking at
you too.

~~~
quink
Char can be anything not " or \\.

You don't have to escape unicode. If you want to just use Unicode and encode
as UTF-8 then go nuts.

This is valid JSON:

{ "äöü": "大家好", "clef": "𝄞" }

~~~
penguindev
I realize that. I'm just sad to see UTF-16 vestiges living on, in current
specs. Who can fathom how much misery and billions of dollars in wasted
productivity (byte order marks - fun!) that wrought upon the IT landscape....

Python has an upper case \UXXXXXXXX literal that seems a lot cleaner.

------
rpedela
Does this mean comments will be added to the spec?

~~~
basicallydan
Nope, sorry.

~~~
eliben
This sucks, because it limits the usability of JSON. It should interfere with
its being a serialization and interchange format, but for configuration files
anything without comments is useless.

~~~
jbrooksuk
[https://plus.google.com/118095276221607585885/posts/RK8qyGVa...](https://plus.google.com/118095276221607585885/posts/RK8qyGVaGSr)

~~~
swift
That's pretty laughable. What exactly prevents people from putting parsing
directives in a special object key or list entry at the beginning of the file?

~~~
phpnode
that would be valid JSON, so it's not a problem. Standard tools can still
parse it and reliably turn it into native objects. The same is not at all true
when comments exist. People will start putting /* @annotations */ that can
only be ready by certain tools which breaks the whole point of JSON - it's a
data interchange format.

~~~
MichaelGG
That sounds smart on first pass, but doesn't really help. If people were going
to use /* @annotations _/ and instead put them in keys, either way, the other
side gets a document that _isn't the one intended*. So regardless if it parses
or not, it doesn't really help.

~~~
phpnode
Let's assume JSON supports comments, and `foo` is a JSON document with
comments, what should happen here?

    
    
        JSON.stringify(JSON.parse(foo))
    

Presumably you'd say that it should return a plain JSON object without
comments, right? However, with the current implementation this will return a
JSON document that is identical to the input, modulo whitespace. This makes it
easy to write tools that can, for example, increment the version number in a
nodejs package.json file programatically. Doing this in a world where comments
exist becomes extremely awkward or at the very least annoying, because either
you have to write your own JSON parser that preserves comments, or you have to
simply discard the comments when you're writing the file.

If you go with the first option, you'll inevitably run into a scenario where
you have a document like this contrived example:

    
    
        {
          // this is the first ever version!
          "version": "1.0.0"
        }
    

And your tool goes off and increments the version number, so you end up with:

    
    
        {
          // this is the first ever version!
          "version": "2.0.0"
        }
    

and now your comment is a lie.

If you go with the second option, you destroy all comments whenever you write
data back to the file, so they can be deemed temporary at best.

What benefit do you actually get from having comments in either scenario?

~~~
swift
Comments are appropriate in JSON which is written by humans. If it's written
by a machine, of course comments are irrelevant. Situations where you need to
automatically make changes to JSON which is primarily maintained by humans are
a bit of a special case that I don't think is worth optimizing for; if you
feel putting comments in object fields is a better choice in this situation,
you can still do that even if comments are supported.

Supporting comments makes JSON more convenient to use in more situations, and
it doesn't prevent you from doing anything you can do now.

------
je_bailey
Can anyone go into the detail of the impact ,if any, of this?

~~~
Cthulhu_
I'm guessing it may help bring JSON to use in the more restrictive companies
that are scared of 'nonstandard' file formats. The kind that currently uses
XML for everything.

~~~
octo_t
the kind that _correctly_ uses XML for everything.

~~~
ensignavenger
Why do you believe that using XML is better than JSON in every case? Or am I
misinterpreting your comment?

~~~
sigzero
I took it as sarcasm. The "for everything" was the tell.

~~~
jlgreco
Poe's Law; it's impossible to tell. There are presumably some companies who
think that using XML for everything is appropriate, so it stands to reason
that there actually are people who believe that as well.

------
samatman
To summarize the top HN complaints: No date format, no comments, needlessly
strict commas.

Is it too late for edn? [https://github.com/edn-
format/edn](https://github.com/edn-format/edn)

Symbols that aren't "strings" are kinda neat too, and you get downright
attached to arbitrary key-value mappings once you have them.

------
ape4
They say JSON is not for binary and won't change. With a backslash (oops
reverse solidus) you could send binary data - eg an image. { myimage:
"\01\02\03" } of course, not efficient. You could base64-encode it and put
that in a string. I think some syntax for binary would be useful - eg {
myimage: 0x010203 }

~~~
chimeracoder
The slash and the solidus are two separate entities. I am not aware of any use
of the actual solidus being used for escaping.

~~~
ape4
I am talking about BACKslash (REVERSE solidus). This says they are the same:
[http://en.wikipedia.org/wiki/Backslash](http://en.wikipedia.org/wiki/Backslash)

~~~
chimeracoder
Interesting. It says they're the same thing, but then the two characters
listed on the page (the regular backslash and the Unicode variant) are
rendered noticeably differently.

I can't imagine why they changed the name, given that the forward slash and
the solidus are _not_ interchangeable.
[http://www.fileformat.info/info/unicode/char/5c/index.htm](http://www.fileformat.info/info/unicode/char/5c/index.htm)

~~~
nknighthb
Look at the HTML. The "unicode variant" is rendered differently because the
code tells the browser to render it differently, not because it's a different
character.

    
    
        <span style="font-size:125%"><span class="Unicode">\</span></span>

~~~
chimeracoder
Ah, thanks. I was on my phone and didn't think to check the source.

 __EDIT __: Actually, this explanation is
enlightening:[http://en.wikipedia.org/wiki/Slash_(punctuation)#Encoding](http://en.wikipedia.org/wiki/Slash_\(punctuation\)#Encoding)

------
xioxox
No Infinity and NaN :-(

------
EzGraphs
Would have been nice if a standard format for hyperlinks were added. This
lacks the elegance of pure JavaScript but it would make it possible to create
strict RESTful APIs that don't violate HATEOAS or includes links as some sort
of extension.

------
chj
One problem: the standard doesn't say whether the names in an object should be
UNIQUE.

~~~
jaredmcateer
JSON is a subset of JavaScript (a few bugs notwithstanding) so you must
conform to it's spec and then JSON adds further restrictions on the language
in it's spec.

------
logician76
So the standard says a valid JSON text complies to the JSON value grammar. So
a valid JSON text can be just one JSON value, like a number or true or false..
however JSON linters always say they expect a { or [ ... who is right?

~~~
logician76
[http://jsonlint.com/](http://jsonlint.com/) expects [ or { first.
[http://zaach.github.io/jsonlint/](http://zaach.github.io/jsonlint/) does not
and seems to comply to the standard as I interpret it.

------
adam-f
Figure 5: String, seems to allow actual newlines strings, that's not a subset
of javascript.

------
optymizer
Awesome, now let's get JSON Schema standardized so I can use it in production.

------
appplemac
404 Standard Not Found

------
mckoss
Spec not Found? ;-)

------
eonil
Why 404.

------
AsymetricCom
JSON is a great way to make your data accessible to deep packet scanning
systems. Define all your protocols with JSON!

~~~
danabramov
You may as well make this argument against human speech. We need secure
transport, not gibberish protocols.

~~~
AsymetricCom
Not really even a close metaphor, since human speech isn't a _internet
standard_ I could build devices against and sell to customers as compliant.

Considering that DPI devices are already sold to parse json-desribed protocols
dynamically, I think you are a bit uninformed about my statement. It is not
hypothetical.

~~~
icebraining
Some DPI software also processes English, should we stop using it?

If you want security, you need encryption, not obscure encoding formats.

------
ollybee
If he want to be formalis JSON e he should use a standard license for the
software.

I accept "The Software shall be used for Good, not Evil." is amusing and
"good" but must cause difficulties for people wanting to package with other
software under standard licenses.

~~~
nknighthb
That is the license on just one of dozens, perhaps hundreds of JSON
implementations. It has nothing _at all_ to do with standardization of the
format.

