Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ecma-international.org

Post reply on HN
Print view View original

151–160 of 199 posts

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

#151

Post by troels »

jmulho wrote: post #72
Stratoscope wrote: post #66

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, includi…

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

I suppose it explains how SOAP came about ...

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

#152

Post by 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

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

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

#153

Post by bronson »

mercurial wrote: post #122
MichaelGG wrote: post #91

Earlier quoted context omitted.

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.

At least you can inspect the document you got with normal tools. Not so if you include comments. And this may even encourage people into separating the data payload from the metadata, who knows?

That sounds like a "no true scotsman" argument. If comments were added to the spec then normal tools would support them just fine.

Besides, JSON has already become a common format for config files. Config files that don't allow comments are truly a step backward.

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

#154

Post by penguindev »

quink wrote: post #141
penguindev wrote: post #101

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

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

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.

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

#155

Post by [deleted] »

quink wrote: post #141
penguindev wrote: post #101

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

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

[deleted]

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

#156

Post by jcampbell1 »

jonny_eh wrote: post #103
jcampbell1 wrote: post #85

Earlier quoted context omitted.

I do use a real parser, but it is not possible for JSON-P.

Don't use JSONP.

I suppose you have a better way to do cross-platform cross-domain APIs? Enlighten us. Facebook and Google use this method, and I assume it is because there isn't a better way.

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

#157

Post by duaneb »

angersock wrote: post #139
duaneb wrote: post #100

Earlier quoted context omitted.

Yes, that solution OBVIOUSLY removes the need to spend an extra minute adding comments to the spec. Also, I hope, trailing commas and binary types.

Shoving binary into JSON is rather silly--base 64 encode it, or consider using a binary format better suited to your need. As for adding comments to the spec--again, the idea is to prevent shadow information showing up that isn't obvious to a conformant parser. If you give people the ability to smuggle data in comments, that's exactly what they'll do. At least this way people know that what they're doing isn't "to sp…

I mean, JSON itself is rather silly in that it's a horrible serialization language. Its main boon is its C-style syntax, which is why it's so readable to all of us who read similar syntaxes all day. Even just a syntactical change noting which strings were base64 encoded would be nice.

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

#159

Post by undershirt »

Touche wrote: post #94
undershirt wrote: post #64

Earlier quoted context omitted.

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.

Why do you manually code json?

I built a game that uses JSON for metadata and config files.

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

#160

Post by TazeTSchnitzel »

curveship wrote: post #138

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…

>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""
Post reply on HN