Hacker News new | past | comments | ask | show | jobs | submit login

I agree with those who say JSON should never change, but should one day be replaced. It behooves us to think about what that replacement should be.

My own peeves:

* Numbers are stored in decimal but usually interpreted as binary with no guidance about rounding.

* The concatenation of valid JSON blobs is never valid JSON.

* The empty string is not valid JSON.

The last two can be "fixed" by a format called "arraySON" where the global blob represents not a JSON object (dictionary), but the contents of an array plus an optional trailing comma.

Or given some of the ideas on this thread, perhaps a manadatory leading comma.




I'd see a trailing or leading comma as a potentially null, or undefined. It's intentionally against spec. I personally see the concatenation an issue in particular with streaming. Streaming JSON objects and parsing them on the fly is a pain, usually requiring a SAX parser. To concat two objects though, I feel like you could just merge the two, if you are okay with appending two arrays, if you had to merge two JSON objects you could. Numbers I seen issues with, I've had to store numbers as strings before, there is guidance however, the official ECMA-404 spec for JSON says there can be any number of digits following a "." in numbers, then optionally followed by an "e", "+" or "-" and more digits. For parsing then, it would be limited by the data types available to the parser. Since JavaScript itself is 17, so that would be the default maximum for JSON IMHO. However, different libraries for different languages may not have 17 for the native decimal types.


> * The concatenation of valid JSON blobs is never valid JSON.

You might want to check out JSON Lines:

http://jsonlines.org/


Is there are formal defintion of the format anywhere?




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: