SJSON support

[bmuzzin]

SJSON is "Simplified JSON", which is a format used in some Autodesk products. http://help.autodesk.com/view/Stingray/ENU/?guid=__stingray_help_managing_content_sjson_html

The SJSON format has the following differences from standard JSON:

• [ ] The equal sign = is used to define key-value pairs instead of the colon :.
• [ ] Quotes around string keys in key-value pairs are optional, unless you need the key to contain either spaces or the equal sign =.
• [ ] Commas are optional in object and array definitions.
• [x] Comments are allowed, using the C and C++ commenting styles: // begins a single-line comment that causes everything to be ignored until the end of the line; / ... / creates a multi-line comment that causes everything between the asterisks to be ignored.
• [ ] Each SJSON file is always interpreted as a definition for a single object. You can think of this as an implicit set of curly quotes { ... } that surround the contents of the file.

This has some overlap with a relaxed JSON #36 implementation. Comments are already implemented, and keys without quotes are also part of relaxed JSON.

https://github.com/Autodesk/sjson

[ArcticLampyrid]

SJSON is quite different form JSON and JavaScript(ECMAScript),so I think it needs a separate library

But I think we need to provide a flag to support JSON5 becasue now more and more JSON are written by humans and JSON5 is a subset of JavaScript

JSON is a short for JavaScript Object Notation

[andrusha97]

@1354092549 What are the exact reasons to be compatible with javascript? I don't see how json5 is better to be in rapidjson than sjson. Both are "unofficial" extensions to json, and both could have their users if implemented in rapidjson.

[ArcticLampyrid]

@andrusha97 SJSON is not compatible with JSON JSON5 is a superset of JSON

If you just need to be simple,why not use YAML? YAML is simpler than JSON/SJSON/JSON5

[ArcticLampyrid]

And it's very surprising that it is called JSON but isn't compatible with JavaScript

[bmuzzin]

SJSON is very similar to JSON, although cannot be directly interpreted in Javascript. The intention of all these 'extensions' to JSON is to make it more human readable/editable, and many of the differences from JSON between them are similar. They could be implemented as small additional features on the rapidjson parser/writers, and combinations of flags can be used to implement different flavors of these extensions (see my PR #1025).

Also, I (unfortunately) don't have a choice on which format to use. The data I have read/write is in SJSON format, and I want to code in C++ (there already is a SJSON parser for Javascript). Since rapidjson could support this with small modifications, it seemed like a natural choice. I can use that PR as a library in my project, but I would love to have this functionality in an official branch.