-
Notifications
You must be signed in to change notification settings - Fork 12
Proposal: support JSON+Comments #6
Comments
No, the JSON spec does not allow comments. |
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. |
That statement is taken out of context. The full message:
Further down the JSON+Comments page, you'll find more recent
I missed that. Thanks for calling it out. That statement is kind of appalling. First of all, no JSON tool is A huge part of the value of JSON is its extreme simplicity and
Are you sure? I count 140 JSON tools linked at at the bottom of I agree that it would be nice to have consistency across all decoders. |
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.
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. |
I think JSON, with or without comments, is lousy for configuration files. This seems like a good opportunity for a separate tool to solve the |
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.cf intridea/multi_json#38
The text was updated successfully, but these errors were encountered: