Proposal: support JSON+Comments
jamesarosen opened this issue · comments
Most other JSON decoders strip out //...\n and /*...*/ comments before processing. ok_json is one of the few that does not. The JSON spec does not require decoders to do so, but it does offer the option. It would be nice to have consistency across all decoders.
No, the JSON spec does not allow comments.
See http://www.ietf.org/rfc/rfc4627.txt
According to the JSON+Comments proposal, Crockford says "A JSON encoder MUST NOT output comments. A JSON decoder MAY accept and ignore comments."
RFC4627, §4 states, "A JSON parser MAY accept non-JSON forms or extensions." So it's certainly allowed.
"A JSON encoder MUST NOT output comments. A JSON decoder MAY accept and ignore comments."
That statement is taken out of context. The full message:
JSON does not have comments. A JSON encoder MUST NOT output comments.
A JSON decoder MAY accept and ignore comments.Comments should never be used to transmit anything meaningful. That is
what JSON is for.
Further down the JSON+Comments page, you'll find more recent
statements from Crockford explaining why comments in JSON do
more harm than good. I agree with his reasoning.
RFC4627, §4 states, "A JSON parser MAY accept non-JSON forms or extensions." So it's certainly allowed.
I missed that. Thanks for calling it out.
That statement is kind of appalling. First of all, no JSON tool is
allowed to generate non-JSON forms or extensions, and any tool
that does so has a bug. So there's no good reason to accept them.
It only encourages buggy encoders.
A huge part of the value of JSON is its extreme simplicity and
uniformity. That can only be maintained if JSON processing tools
resist the urge to extend it.
Most other JSON decoders strip out
//...\nand/*...*/comments
Are you sure? I count 140 JSON tools linked at at the bottom of
http://json.org/. How many of them strip comments?
I agree that it would be nice to have consistency across all decoders.
The best way to achieve that is for all decoders to stick closely to the
JSON spec, with no extensions.
I count 140 JSON tools linked at at the bottom of http://json.org/. How many of them strip comments?
Sorry, I meant to say most of the Ruby ones do, but even there I'm wrong. Of the ones that multi_json supports, only oj and ok_json don't. You can see the tests here. Of the three listed on http://json.org/, only yajl-ruby strips comments. Overall, it's quite mixed.
First of all, no JSON tool is allowed to generate non-JSON forms or extensions, and any tool that does so has a bug. So there's no good reason to accept them. It only encourages buggy encoders.
Here I have to agree with Kyle Simpson (the author of the article I linked) -- JSON+Comments is great for configuration files. JSON alone is rather lousy.
JSON+Comments is great for configuration files. JSON alone is rather lousy.
I think JSON, with or without comments, is lousy for configuration files.
(I also think configuration files are lousy in the first place.) But that's all
a matter of opinion. Are there any other use cases for comments?
This seems like a good opportunity for a separate tool to solve the
problem, rather than modifying a general-purpose JSON library for one
peculiar situation.