Hacker News Reader

Comment by swift | Hacker News Reader

Crockford's explanation is pretty absurd, though.

It makes perfect sense -- if you provide a freeform content section of an otherwise strictly formed document (for interoperability reasons), then people will abuse it to store arbitrary, uninteroperable data (as was seen with binary blobs being dumped into XML).

The point of a standardized serialization format is well-defined parsing semantics and universal interoperability.

I thought xml was developed to be able to include binary parts on purpose since it can be useful.

And you can't base64 encode it and store it in a string?

Indeed. I see SQL comments and Postgres COMMENT ON statements used to send information to applications. Really funny, that....

Except that in practice, this has just meant that people have defined their own ad-hoc extensions to JSON that add support for comments, since it's so useful for stuff like JSON-formatted config files.

It's also meant that JSON documents don't have data encoded in comments. Working as intended.

>It makes perfect sense -- if you provide a freeform content section of an otherwise strictly formed document (for interoperability reasons), then people will abuse it to store arbitrary, uninteroperable data (as was seen with binary blobs being dumped into XML).

That will then be their own bloody problem, not Crockfords.

How so?

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

Seems like a perfectly fine way to have comments (if you absolutely need them) in a production environment.

Presumably JSMin removes optional quotes in object laterals, so it probably doesn't output valid JSON.

That would be a pretty big mistake for the author of both the JSON spec and JSMin to make? Maybe it is but it seems unlikely.

JSMin is not the right tool for this. I'm sure it conforms to the JavaScript (ECMAScript) spec but probably not the JSON spec. Here's a trivial JavaScript function to convert JSON5 to regular JSON with no comments and quoted identifiers and all that good stuff:

function JSON5_to_JSON(str) { return JSON5.parse(str).stringify(); }

This is exactly what is suggested in the Usage section of the linked article.

If the author of the JSON spec and JSMin says it's the right tool for the job, I am inclined to trust him on that barring further evidence that it is not...

Since when does Crockford say that JSMin is the right tool for this particular job: translating JSON5 into regular JSON?

Reply on news.ycombinator.com