4 ms·

I was thinking along very similar lines when reading the article by Tim Bray. JSON is designed for JavaScript compatibility, I almost stopped reading when he sa

by xvolter 10y ago

I was thinking along very similar lines when reading the article by Tim Bray. JSON is designed for JavaScript compatibility, I almost stopped reading when he said: > They’re inessential to the grammar, just there for JavaScript compatibility. The entire article goes on to suggest extremely terrible solutions to the problems he is pointing out. In order: Commas: If comma's are an annoyance, is that to mean there is no annoyance with XML markup? You can forget a closing tag just as easily, probably more easily. Just get a JavaScript or JSON linter. Fixed. If you are really annoyed by commas, move to YAML or another format. Datetimes: Just store your dates in a standardized timezone and format, how about [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601). You can also use a [JSON-Schema](http://json-schema.org/ http://json-schema.org/) if you really want. Schemas: There's lots of potentials here. However, again, if you're going to change JSON so much, why not just pick another data format that has better schema support.

sopooneo 10y ago
For datetimes, do you mean that they be set as strings in the standardized formats such as specified by ISO 8601? Like: {"item": "lawn chair", "order-timestamp": "2016-08-21T00:58:47Z"}
- xvolter 10y ago
  Yes, that would be a strongly recommended way. I could see using a unix timestamp as a numeric field as another way.
rat87 10y ago
> JSON is designed for JavaScript compatibility, Javascript compatibility is the least important part of json, lots of people use json with python or ruby or rust or java or c for things that will never interact with javascript, and anyways you don't want people to parse json with eval or confusing json with things that include string concatenation or function calls adding non javascript syntax helps make that clear. There is a good reason to not change JSON(backwards compatibility, updating parsers, confusing formats, ect.), since you're not planning on parsing javascript with eval there is no good reason why any changes made in JSON 2.0 have to conform to a subset of javascript.
- xvolter 10y ago
  I think if breaking changes are made, there is no point, it would not be called JSON 2.0; it is an entirely new data format. When there are hundreds to thousands of alternatives, trying to "fix JSON" isn't the solution. JSON works because it is simple and easy to follow, it is robust and flexible, and has no restrictions. There is no good way to store dates in XML or many other formats, without the use of Schemas, and the syntax changes are minimally beneficial. It wouldn't save a lot of bandwidth with gzip, and the text data likely doesn't add up to a lot of disk space when compared to the data being stored; so removing commas which make parsing JSON easy and increases its adoption and usage, just so some people can have less linting errors doesn't seem like a large benefit.
anon1385 10y ago
>JSON is designed for JavaScript compatibility, I almost stopped reading when Why does Javascript compatibility matter in 2016? The original idea for JSON might have been to parse untrusted data using js eval() but I'd hope that nobody is doing that anymore.
- xvolter 10y ago
  I don't believe the original purpose of JSON was to eval untrusted objects, since that would always have posed a security risk. It did however offer a very easy standard way to share and parse data back in 1999. In 2016, I believe continued backwards compatibility is a necessity; otherwise you are just creating a new data storage format. So removing commas doesn't seem like an acceptable improvement, especially when the recommendation comes out of a necessity due to human error while hand-editing. JSON is incredibly easy to read and write by hand, in comparison with XML it is far easier to parse and traverse through code do its significantly simplified structure. If however, you need more functionality, switch to a different format; why bother trying to mangle or force JSON to work where it doesn't. There are other technologies and standards out there, use them.
  - macspoofing 10y ago
    >It did however offer a very easy standard way to share and parse data back in 1999. Not 1999. 2004. JSON wasn't on anybody's radar in 1999. >JSON is incredibly easy to read and write by hand, in comparison with XML Maybe for small shallow objects (and for those XML is also quite readable). Once size or complexity get a little higher, you're done.
    - hutzlibu 10y ago
      > Once size or complexity get a little higher, you're done. And what is better than JSON, when it gets complex?
      - macspoofing 10y ago
        I meant you're done with reading and writing it by hand.
JimDabell 10y ago
> If comma's are an annoyance, is that to mean there is no annoyance with XML markup? You can forget a closing tag just as easily That's not the same thing at all. The commas in JSON are equivalent to the whitespace between attributes in XML. A missing closing tag in XML would be equivalent to forgetting to close an object literal or array in JSON. So no, there's no equivalent XML annoyance to what he's asking for, XML is already fixed in the manner he suggests.
Mikhail_Edoshin 10y ago
The issue is not about forgetting something. XML elements are self-contained, you don't need to separate them, thus you don't need to known the context. If you generate XML programmatically, each function can just push its object into the stream and be done. With JSON you need to know if your object is last or first at this level of hierarchy, so you know if you need to insert a comma or not. Commas were meant to be used in code that you actually type. Using them as separators in a format that is meant to be produced and consumed by computers is clear, simple, and wrong.

by xvolter 10y ago

sopooneo 10y ago

For datetimes, do you mean that they be set as strings in the standardized formats such as specified by ISO 8601? Like: {"item": "lawn chair", "order-timestamp": "2016-08-21T00:58:47Z"}

xvolter 10y ago
Yes, that would be a strongly recommended way. I could see using a unix timestamp as a numeric field as another way.

rat87 10y ago

> JSON is designed for JavaScript compatibility, Javascript compatibility is the least important part of json, lots of people use json with python or ruby or rust or java or c for things that will never interact with javascript, and anyways you don't want people to parse json with eval or confusing json with things that include string concatenation or function calls adding non javascript syntax helps make that clear. There is a good reason to not change JSON(backwards compatibility, updating parsers, confusing formats, ect.), since you're not planning on parsing javascript with eval there is no good reason why any changes made in JSON 2.0 have to conform to a subset of javascript.

xvolter 10y ago
I think if breaking changes are made, there is no point, it would not be called JSON 2.0; it is an entirely new data format. When there are hundreds to thousands of alternatives, trying to "fix JSON" isn't the solution. JSON works because it is simple and easy to follow, it is robust and flexible, and has no restrictions. There is no good way to store dates in XML or many other formats, without the use of Schemas, and the syntax changes are minimally beneficial. It wouldn't save a lot of bandwidth with gzip, and the text data likely doesn't add up to a lot of disk space when compared to the data being stored; so removing commas which make parsing JSON easy and increases its adoption and usage, just so some people can have less linting errors doesn't seem like a large benefit.

anon1385 10y ago

>JSON is designed for JavaScript compatibility, I almost stopped reading when Why does Javascript compatibility matter in 2016? The original idea for JSON might have been to parse untrusted data using js eval() but I'd hope that nobody is doing that anymore.

xvolter 10y ago
I don't believe the original purpose of JSON was to eval untrusted objects, since that would always have posed a security risk. It did however offer a very easy standard way to share and parse data back in 1999. In 2016, I believe continued backwards compatibility is a necessity; otherwise you are just creating a new data storage format. So removing commas doesn't seem like an acceptable improvement, especially when the recommendation comes out of a necessity due to human error while hand-editing. JSON is incredibly easy to read and write by hand, in comparison with XML it is far easier to parse and traverse through code do its significantly simplified structure. If however, you need more functionality, switch to a different format; why bother trying to mangle or force JSON to work where it doesn't. There are other technologies and standards out there, use them.
- macspoofing 10y ago
  >It did however offer a very easy standard way to share and parse data back in 1999. Not 1999. 2004. JSON wasn't on anybody's radar in 1999. >JSON is incredibly easy to read and write by hand, in comparison with XML Maybe for small shallow objects (and for those XML is also quite readable). Once size or complexity get a little higher, you're done.
  - hutzlibu 10y ago
    > Once size or complexity get a little higher, you're done. And what is better than JSON, when it gets complex?
    - macspoofing 10y ago
      I meant you're done with reading and writing it by hand.

JimDabell 10y ago

> If comma's are an annoyance, is that to mean there is no annoyance with XML markup? You can forget a closing tag just as easily That's not the same thing at all. The commas in JSON are equivalent to the whitespace between attributes in XML. A missing closing tag in XML would be equivalent to forgetting to close an object literal or array in JSON. So no, there's no equivalent XML annoyance to what he's asking for, XML is already fixed in the manner he suggests.

Mikhail_Edoshin 10y ago

The issue is not about forgetting something. XML elements are self-contained, you don't need to separate them, thus you don't need to known the context. If you generate XML programmatically, each function can just push its object into the stream and be done. With JSON you need to know if your object is last or first at this level of hierarchy, so you know if you need to insert a comma or not. Commas were meant to be used in code that you actually type. Using them as separators in a format that is meant to be produced and consumed by computers is clear, simple, and wrong.