9 ms·

Shameful confession: when I was first introduced to JSON, I was convinced it would go nowhere. "XML already does everything JSON does! And there's no way to dif

Shameful confession: when I was first introduced to JSON, I was convinced it would go nowhere. "XML already does everything JSON does! And there's no way to differentiate between nodes and attributes! And there are no namespaces! And no schemas! What's the point of JSON?" And a couple of years later I looked up from the tangled mess of XSLT I was working on to discover that the rest of the world had moved on. JSON is just javascript, and it leaves out everything else. That's its entire reason for existing, and it caught on because that's all that 99.44% of anyone needed. Timestamps you can add today, without changing the protocol; just put them in your data if you need them. So I'm not sure what he's even proposing there. Schemas: OK, he doesn't like JSON Schema's anyOf. Fair enough. There's no real proposal here for how to fix it, so not much to say here. Replacing commas with whitespace sounds to me like replacing a very minor irritant with a constant full-body rash. Stuff like his example of "IDs": [ 116 943 234 38793 ] would lead to far more confusion and errors than the occasional stray trailing comma. So I guess I pretty much vote no on this one thanks for asking

rkrzr 10y ago
"Timestamps you can add today, without changing the protocol; just put them in your data if you need them. So I'm not sure what he's even proposing there." He is proposing to add a timestamp type to the grammar. This would have the advantage that there would be one canonical way to have timestamps in your JSON. It would also mean that the parser would already validate them for you and you would not have to do that yourself every time. I definitely see value in that.
- geezerjay 10y ago
  > He is proposing to add a timestamp type to the grammar. This would have the advantage that there would be one canonical way to have timestamps in your JSON. There is already a canonical way to have timestamps: encode them as defined in RFC 3339. Done. The proposals add nothing to JSON and don't make sense. I mean, screwing up with the language just to add a very specific data type that is used in only a specific corner case that isn't even supported in the use case that's provided as an example? Nonsense.
  - sopooneo 10y ago
    Are you proposing that timestamps as described in RFC 3339 be put inside quotes and just be string values in JSON? That's the simplest way I can think to do it, but I've had adamant protest to that idea. If you are not suggesting that timestamp values be wrapped in quotes, then wouldn't you have to worry about every existing parser out there tripping on them?
    - Ericson2314 10y ago
      The former I assume. It sounds fine to me. if one is worried aboutfragmentstion, create a standard on top JSON that provides rules for dealing with other types. Layering 101, people!
  - JimDabell 10y ago
    > There is already a canonical way to have timestamps: encode them as defined in RFC 3339. That's not canonical at all. It's not even a de facto use of timestamps in JSON; most specifications I see call for ISO 8601. > Done. Well no, not done, because you then have to wrap it in a string, which essentially hides it from the JSON parser altogether and moves responsibility for parsing it out of the JSON parser into your application. As far as the JSON parser is concerned, it could be any old string, not a timestamp. > a very specific data type that is used in only a specific corner case I don't see how you can call timestamps a corner case – the article says "Among the RESTful APIs that I can think of, exactly zero don’t have timestamps." – and my experience is the same. Pretty much every API I've worked with has used timestamps in some form or another. They aren't a corner case at all – aside links, they are probably the most common data type without direct support in JSON.
    - geezerjay 10y ago
      > That's not canonical at all. It's not even a de facto use of timestamps in JSON; most specifications I see call for ISO 8601. Nonsense. ISO 8601 is an ISO standard that defines representations of dates and times. Date and time representations aren't timestamps. RFC 3339 is based on ISO 8601 but is designed specifically to handle timestamps by including provisions that tackle interoperability problems that ISO 8601 does not handle. > Well no, not done, because you then have to wrap it in a string Nonsense. JSON is just the languge that is used as a superset for other domain-specific languages. How the other language defined (and parsed) isn't handled by the JSON parser, obviously. Considering Tim Bray's example, If a domain-specific language specifies that a "Capture time" string is followed by a string storing an RFC 3339 timestamp, that's precisely what the parser for the domain-specific language is expected to parse. The document remains valid JSON, and the domain-specific language remains valid. > I don't see how you can call timestamps a corner case Because it is. It isn't a primitive data type, nor is it required to implement generic data structures. Hell, some programming languages don't even support any standard date and time container or aggregate data type. Timestamps are a very specific data type whose application is limited to very specific corner cases that are already handled quite well by other means.
- andy_ppp 10y ago
  meteor ejson format adds a consistent timestamp format with breaking current Jason parsers.
ubernostrum 10y ago
So I guess I pretty much vote no on this one thanks for asking Yeah, this is precisely the kind of stuff people said would cause JSON to "lose" to XML -- how could you ever build anything without schemas and types and bunches of metadata to ensure you were using it correctly? And this debate is not new; it's been around a long time, and I wrote about it at length literally ten years ago: http://www.b-list.org/weblog/2006/dec/21/i-cant-believe-its-not-xml/ http://www.b-list.org/weblog/2006/dec/21/i-cant-believe-its-...
Normal_gaussian 10y ago
> Replacing commas with whitespace sounds to me like replacing a very minor irritant with a constant full-body rash Both vivid and accurate. In order to combat trailing commas I normally place the comma on the following line, e.g. { "time": "3 minutes past four" , "age": 229 , "sex": "monoecious species" , "appearance": "Tree-like. It's a tree." } uint8_t *data // Yada , *buffer // Ya ; var javascript , variable = 6 , declarations = [ "This is taking too long", "Yep" ] , mix = [ "Flour", "Sugar", "Water" ] , types = { 'old' : (d) => { return d < new Date } , 'new' : (d) => { return d > new Date } , 'borrowed': (o) => { return false } , 'blue' : (c) => { return true } } , regularly = new Date().toISOString() ; With such a format there is only ever a problem deleting the first line, which I find is much much harder to do without also noticing what you've done to the larger statement.
- yepperino 10y ago
  > In order to combat trailing commas I normally place the comma on the following line Ah okay, so you're that guy whose code I have to reformat in every new job.
  - Normal_gaussian 10y ago
    I highly recommend having a couple of reformatting scripts around - its a great way to find logical errors quickly. Of course don't commit reformats where it diverges from the codebase.
  - ketralnis 10y ago
    If you're having to do it on every job, maybe you're the unusual one
    - yepperino 10y ago
      Weirder still - why do I follow him from job to job?
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.
rat87 10y ago
> JSON is just javascript, Today json is not really tied to javascript that much, I deal with it all the time in python that doesn't include or interact with javascript. JSON is just dictionaries and lists (and strings and numbers and nulls) this is pretty easy to express in dynamically typed languages and not that hard in statically typed languages if you give up on a bit of (static) typing. I don't see any reason why it should be limited to a subset of javascript, there are some good reasons for not changing it all though.
aarreedd 10y ago
Why not just allow trailing commas?
- stevedonovan 10y ago
  Well, totally. Lua and C don't care. A minor change, breaking the strict-subset-of-javascript which is no longer important.
  - rossy 10y ago
    Well, not really. ES5 allows trailing commas in object literals too.
cs02rm0 10y ago
I loved JSON immediately, having hated XML for so long. However, I'd agree with your conclusions. The minor irritations outlined here are less bad than breaking javascript compatibility.
smoyer 10y ago
Except you can put comments in your Javascript ... I'd love to have comments in JSON. It's not so important for machine generated files but when you hand-craft an example it's nice to annotate it.
- sangnoir 10y ago
  > I'd love to have comments in JSON. It's not so important for machine generated files but when you hand-craft an example it's nice to annotate it. Luckily, Douglas Crockford has an explanation and an almost prophetic solution[1] for your use-case: I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. 1. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...
jabits 10y ago
I mostly agree, except I still like and use XML in many cases. XML Schema validation is just too useful as a first pass validation step to verify the "shape" of a message/document. And to me, with any decent editor with folding, it is easy to read. And very importantly, allows comments. I have never understood all the XML-hate out there...
- Mikhail_Edoshin 10y ago
  > I have never understood all the XML-hate out there... Me neither. I think it's truly irrational.

rkrzr 10y ago

"Timestamps you can add today, without changing the protocol; just put them in your data if you need them. So I'm not sure what he's even proposing there." He is proposing to add a timestamp type to the grammar. This would have the advantage that there would be one canonical way to have timestamps in your JSON. It would also mean that the parser would already validate them for you and you would not have to do that yourself every time. I definitely see value in that.

geezerjay 10y ago
> He is proposing to add a timestamp type to the grammar. This would have the advantage that there would be one canonical way to have timestamps in your JSON. There is already a canonical way to have timestamps: encode them as defined in RFC 3339. Done. The proposals add nothing to JSON and don't make sense. I mean, screwing up with the language just to add a very specific data type that is used in only a specific corner case that isn't even supported in the use case that's provided as an example? Nonsense.
- sopooneo 10y ago
  Are you proposing that timestamps as described in RFC 3339 be put inside quotes and just be string values in JSON? That's the simplest way I can think to do it, but I've had adamant protest to that idea. If you are not suggesting that timestamp values be wrapped in quotes, then wouldn't you have to worry about every existing parser out there tripping on them?
  - Ericson2314 10y ago
    The former I assume. It sounds fine to me. if one is worried aboutfragmentstion, create a standard on top JSON that provides rules for dealing with other types. Layering 101, people!
- JimDabell 10y ago
  > There is already a canonical way to have timestamps: encode them as defined in RFC 3339. That's not canonical at all. It's not even a de facto use of timestamps in JSON; most specifications I see call for ISO 8601. > Done. Well no, not done, because you then have to wrap it in a string, which essentially hides it from the JSON parser altogether and moves responsibility for parsing it out of the JSON parser into your application. As far as the JSON parser is concerned, it could be any old string, not a timestamp. > a very specific data type that is used in only a specific corner case I don't see how you can call timestamps a corner case – the article says "Among the RESTful APIs that I can think of, exactly zero don’t have timestamps." – and my experience is the same. Pretty much every API I've worked with has used timestamps in some form or another. They aren't a corner case at all – aside links, they are probably the most common data type without direct support in JSON.
  - geezerjay 10y ago
    > That's not canonical at all. It's not even a de facto use of timestamps in JSON; most specifications I see call for ISO 8601. Nonsense. ISO 8601 is an ISO standard that defines representations of dates and times. Date and time representations aren't timestamps. RFC 3339 is based on ISO 8601 but is designed specifically to handle timestamps by including provisions that tackle interoperability problems that ISO 8601 does not handle. > Well no, not done, because you then have to wrap it in a string Nonsense. JSON is just the languge that is used as a superset for other domain-specific languages. How the other language defined (and parsed) isn't handled by the JSON parser, obviously. Considering Tim Bray's example, If a domain-specific language specifies that a "Capture time" string is followed by a string storing an RFC 3339 timestamp, that's precisely what the parser for the domain-specific language is expected to parse. The document remains valid JSON, and the domain-specific language remains valid. > I don't see how you can call timestamps a corner case Because it is. It isn't a primitive data type, nor is it required to implement generic data structures. Hell, some programming languages don't even support any standard date and time container or aggregate data type. Timestamps are a very specific data type whose application is limited to very specific corner cases that are already handled quite well by other means.
andy_ppp 10y ago
meteor ejson format adds a consistent timestamp format with breaking current Jason parsers.

ubernostrum 10y ago

So I guess I pretty much vote no on this one thanks for asking Yeah, this is precisely the kind of stuff people said would cause JSON to "lose" to XML -- how could you ever build anything without schemas and types and bunches of metadata to ensure you were using it correctly? And this debate is not new; it's been around a long time, and I wrote about it at length literally ten years ago: http://www.b-list.org/weblog/2006/dec/21/i-cant-believe-its-not-xml/ http://www.b-list.org/weblog/2006/dec/21/i-cant-believe-its-...

Normal_gaussian 10y ago

> Replacing commas with whitespace sounds to me like replacing a very minor irritant with a constant full-body rash Both vivid and accurate. In order to combat trailing commas I normally place the comma on the following line, e.g. { "time": "3 minutes past four" , "age": 229 , "sex": "monoecious species" , "appearance": "Tree-like. It's a tree." } uint8_t *data // Yada , *buffer // Ya ; var javascript , variable = 6 , declarations = [ "This is taking too long", "Yep" ] , mix = [ "Flour", "Sugar", "Water" ] , types = { 'old' : (d) => { return d < new Date } , 'new' : (d) => { return d > new Date } , 'borrowed': (o) => { return false } , 'blue' : (c) => { return true } } , regularly = new Date().toISOString() ; With such a format there is only ever a problem deleting the first line, which I find is much much harder to do without also noticing what you've done to the larger statement.

yepperino 10y ago
> In order to combat trailing commas I normally place the comma on the following line Ah okay, so you're that guy whose code I have to reformat in every new job.
- Normal_gaussian 10y ago
  I highly recommend having a couple of reformatting scripts around - its a great way to find logical errors quickly. Of course don't commit reformats where it diverges from the codebase.
- ketralnis 10y ago
  If you're having to do it on every job, maybe you're the unusual one
  - yepperino 10y ago
    Weirder still - why do I follow him from job to job?

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.

rat87 10y ago

> JSON is just javascript, Today json is not really tied to javascript that much, I deal with it all the time in python that doesn't include or interact with javascript. JSON is just dictionaries and lists (and strings and numbers and nulls) this is pretty easy to express in dynamically typed languages and not that hard in statically typed languages if you give up on a bit of (static) typing. I don't see any reason why it should be limited to a subset of javascript, there are some good reasons for not changing it all though.

aarreedd 10y ago

Why not just allow trailing commas?

stevedonovan 10y ago
Well, totally. Lua and C don't care. A minor change, breaking the strict-subset-of-javascript which is no longer important.
- rossy 10y ago
  Well, not really. ES5 allows trailing commas in object literals too.

cs02rm0 10y ago

I loved JSON immediately, having hated XML for so long. However, I'd agree with your conclusions. The minor irritations outlined here are less bad than breaking javascript compatibility.

smoyer 10y ago

Except you can put comments in your Javascript ... I'd love to have comments in JSON. It's not so important for machine generated files but when you hand-craft an example it's nice to annotate it.

sangnoir 10y ago
> I'd love to have comments in JSON. It's not so important for machine generated files but when you hand-craft an example it's nice to annotate it. Luckily, Douglas Crockford has an explanation and an almost prophetic solution[1] for your use-case: I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser. 1. https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaG...

jabits 10y ago

I mostly agree, except I still like and use XML in many cases. XML Schema validation is just too useful as a first pass validation step to verify the "shape" of a message/document. And to me, with any decent editor with folding, it is easy to read. And very importantly, allows comments. I have never understood all the XML-hate out there...

Mikhail_Edoshin 10y ago
> I have never understood all the XML-hate out there... Me neither. I think it's truly irrational.