I agree filtering makes sense, but why run it through a full-blown filter when all I want is to support comments? I think this is a nice efficient and simple tool for just removing comments: https://github.com/kitcambridge/json-compressor
I'm thinking of using that as the main way and only using my custom jison parser when I want to give detailed error messages.
Also a main goal I have is to get it to work in multiple programming languages. Most of my test suite is JSON - it just has a tiny runner that iterates through the test data, so that makes it easy to port. Having a native version could make it easier for users of the other languages.
--- In firstname.lastname@example.org, "douglascrockford" <douglas@...> wrote:
> --- In email@example.com, "Ben Atkin" <ben@> wrote:
> > The standard is respected in most places. Try adding comments and then using a common JSON parser (like the one in Firefox or Chrome) and you'll see an error. Because of that, it's foolish to output JSON that doesn't conform to the spec.
> > I'm not especially interested in the three changes in the original thread. What I do find interesting is comment support. JSON is so nice and simple that it's often being used for configuration and not just serialization. In many cases, comments are more useful than problematic in configuration files. For this reason I'm working on making a standard format that is simply JSON+comments, and I'm calling it Eon (EcmaScript Object Notation). I think if you're going to try to come up with your own JSON-like format, you should come up with a file extension and content-type that doesn't contain "json". Some HTTP client libraries will try to parse everything that has the substring "json" in its content type, and it's best not to break those, even though they should arguably be checking for word boundaries.
> You don't need a new standard. Just pipe JSMin in front of your JSON parser.