ECMA-404: The JSON Data Interchange Format [pdf]

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

by dphnx • 13 years ago

255 192 13 years ago

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...

danabramov2• 13 years ago

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

walid• 13 years ago

HAHAHAHA! I was scanning the comments hoping that I'd be the first to drop the 404 joke :D

I swear the moment I glanced at the title I thought it was an error message that someone accidentally posted.

je_bailey• 13 years ago

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

Cthulhu_• 13 years ago

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• 13 years ago

the kind that correctly uses XML for everything.

ntkachov• 13 years ago

More of a formality than anything else. Since JSON was already defined by Javascript, formalizing it doesn't really engrave the standard, it just gives it the recognition that its not just some whacky thing created by Dave.

Toenex2• 13 years ago

"Dave" being recognised as generic name for any developer.

l-p• 13 years ago

I'd be interested to know if this has any impact on the "don't be evil" clause in the JSON license.

postfuturist2• 13 years ago

That's just a license for software available on json.org, so no impact at all.

Jare2• 13 years ago

My faint hopes for trailing comma support are now crushed.

TallGuyShort• 13 years ago

I'm actually very confused by it - I thought the specification for ECMAScript 3 already specified trailing comma support for JSON. Will need to look it up...

masklinn2• 13 years ago

ECMAScript 3 did not allow trailing commas in object literals, its section 11.1.5 is:

    ObjectLiteral :
        { }
        { PropertyNameAndValueList }

whereas ES5's is:

    ObjectLiteral :
        { }
        { PropertyNameAndValueList }
        { PropertyNameAndValueList , }

And while JSON is strongly inspired by javascript's object notation, it is not actually javascript: their strings are subtly incompatible (JSON allows U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR in quoted strings, javascript does not).

rpedela4• 13 years ago

What does trailing comma support get you?

oneeyedpigeon9• 13 years ago

The ability to be lazy.

mjmahone17• 13 years ago

For large code bases, you don't break git blame by adding in new arguments. And it's one less thing to think about when editing your code: always add a comma, never worry about errors because you need to add a comma to the line above.

swift5• 13 years ago

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.

batbomb• 13 years ago

The ability to use a for-each loop rather than an iterator or iterated for loop.

undershirt2• 13 years ago

I was crossing my fingers for that too. I create JSON files a lot. It's annoying when I'm _reordering_ elements separated by newlines. It's annoying when I'm generating JSON files and I have to code in a special case to skip the comma. It breaks the consistency that I just desire as a programmer.

Touche2• 13 years ago

Why do you manually code json?

TeeWEE2• 13 years ago

Trailing comma's, really?? Its is so fucking ugly and inconsistent. Either ALWAYS have traling commas, or never have it. And since the meaning of a comma is separate two items, a trailing comma makes no semantical sense, the only reason you want it because A) youre lazy B) you dont know howto properly serialize to json (youre doing string manipulation probably C) you never heard about the .join function D) you dont know how to read a diff E) you dont do syntax checks before you deploy your code

Zikes3• 13 years ago

A) Wat.

B) Somebody's gotta write those serialization libraries, and they probably do a fair amount of string manipulation to do so.

C) You can't .join data streams without buffering, which defeats the purpose.

D) Adding commas on a preceding line every time you add a new item to a list can pollute diffs.

E) Trailing commas are syntactically correct in ECMAScript 6, and supported by a fair few other languages.

bcj• 13 years ago

Trailing commas reduce cognitive load. I don't need to consider whether an element I'm adding is the last item in a set; there isn't an edge case. Also, I can more quickly scan a DIFF and see the change in a file.

Jare2• 13 years ago

It's fine to disagree, but you need to calm down.

6cxs2hd6• 13 years ago

Anyone compiling a list of talking points for why s-expressions aren't so crazy after all, should add this to the list. (Just append it to the list, no comma required; i.e. pun sorta intended.)

Touche2• 13 years ago

Does this mean we can now use it for evil?

jerf• 13 years ago

That license issue wasn't about the spec, it was about the implementation. Alas.

oneeyedpigeon9• 13 years ago

No, only for eval ;-)

JulianMorrison• 13 years ago

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

jcampbell16• 13 years ago

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• 13 years ago

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

mmahemoff• 13 years ago

Probably because he's very aware of it already and people here may not be.

(Meta: Why have any conversation on an HN back-channel when there are comments open at the source?)

jcampbell16• 13 years ago

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?

xnxn• 13 years ago

Isn't this a design mistake in JavaScript rather than JSON?

jcampbell16• 13 years ago

No, not really. The JSON standard says you can't put raw newlines in strings, and you must write \n. Why does it say it is okay to put raw unicode line_separator rather than requiring \u2028 ? Two more lines to the spec, and DC's variant of JSON would actually be a subset of Javascript. Instead we are left with an edge case that we are going to have to worry about for the next 20 years.

basicallydan2• 13 years ago

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...

And here's an important one, DVD-RAM discs: http://www.ecma-international.org/publications/files/ECMA-ST... and their cases: http://www.ecma-international.org/publications/files/ECMA-ST...

Plus, NFC: http://www.ecma-international.org/publications/files/ECMA-ST...

It's all new to me!

appplemac• 13 years ago

404 Standard Not Found

rpedela4• 13 years ago

Does this mean comments will be added to the spec?

basicallydan2• 13 years ago

Nope, sorry.

eliben3• 13 years ago

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.

ollybee• 13 years ago

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.

nknighthb2• 13 years ago

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.

seanconaty• 13 years ago

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

fleetfox• 13 years ago

It's not XML

tel2• 13 years ago

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

oneeyedpigeon9• 13 years ago

And a lot of that's fluff (the rails diagrams, boilerplate); you could probably fit it quite comfortably on 1 side of A4 / US letter.

ape42• 13 years ago

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 }

chimeracoder3• 13 years ago

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

ape42• 13 years ago

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

spullara• 13 years ago

A jpg base64 encoded and gzipped is similar in size to the original jpg. It isn't as bad as you might think.

AsymetricCom2• 13 years ago

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

danabramov2• 13 years ago

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

AsymetricCom2• 13 years ago

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.

oneeyedpigeon9• 13 years ago

Why can the solidus (/) be escaped?

oneeyedpigeon9• 13 years ago

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• 13 years ago

thanks. was wondering the same...

adam-f• 13 years ago

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

Stratoscope6• 13 years ago

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...

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

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...

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

tedivm2• 13 years ago

You mean Douglas Crockford broke down and gave into the "pro-evil fanatics"?

For context, after Mr. Crockford gave IBM permission to use the license without the clause a few open source projects (mine included), also asked, and Mr. Crockford's response was a bit over the top-

I released to free use for all with the only condition that it not be used for evil. If that is unacceptable to you, then you may not use it. Your options are to bend to the pro-evil fanatics, or to find a more reasonable hosting solution.

It's nice to see he's become a bit more reasonable.

MichaelGG8• 13 years ago

"Pro-evil"? Wow. Is it so hard for people to realise the problem is the potential interpretation of "evil" is very open ended?

jmulho• 13 years ago

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

alexhawdon• 13 years ago

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

troels• 13 years ago

I suppose it explains how SOAP came about ...

mikeryan• 13 years ago

You can feel free to use json2.js for good or evil.

The NSA breathes a sigh of relief.

squirrel• 13 years ago

I actually enjoyed going to my boss at TIM Group (financial services software, in the City of London) and asking him whether he was comfortable asserting in our open-source audit that we did Good rather than Evil. He thought for a moment - and knowing him, he really did think about it - and then opined that he was, indeed, comfortable that we were doing Good. We proceeded to use JSON happily for years.

Stratoscope6• 13 years ago

That is the best Good vs. Evil story of all!

eonil• 13 years ago

Why 404.

logician762• 13 years ago

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?

logician762• 13 years ago

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

xioxox• 13 years ago

No Infinity and NaN :-(

EzGraphs• 13 years ago

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.

penguindev2• 13 years ago

"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• 13 years ago

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": "𝄞" }

penguindev2• 13 years ago

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.

mckoss• 13 years ago

Spec not Found? ;-)

optymizer4• 13 years ago

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

curveship2• 13 years ago

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 ). 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• 13 years ago

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""

curveship2• 13 years ago

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.

samatman• 13 years ago

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

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

minor_nitwit• 13 years ago

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

chj• 13 years ago

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

jaredmcateer3• 13 years ago

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.

ECMA-404: The JSON Data Interchange Format [pdf]

Related Stories