Re: [Json] Human JSON (Hjson)

[Sean Leonard <[e-mail]>]

On 5/24/2016 2:36 PM, Christian Zangl wrote:
> JSON is used in a lot of places and has helped improve things like 
> data exchange and data storage. It is also used in areas it's less 
> suited for, like configuration files. People seem to prefer JSON for 
> configuration over YAML and other config formats.
>
> I started Human JSON (Hjson) because I found the experience 
> frustrating (for example missing/trailing comma problems, no 
> comments). With Hjson you get a superset of JSON that allows you to
>
> - add #, // or /**/ comments,
> - omit quotes for keys,
> - omit quotes for strings (terminated by LF, no escapes),
> - omit braces for the root object,
> - omit the comma at the end of a line
> - add trailing commas and
> - use multiline strings with proper whitespace handling.
>
> These changes should make it easer to read and write configs while 
> still preserving the power of JSON.

> Thoughts?

I read through the document with interest. It's a nice idea. I don't 
discourage it in general. But...

It seems that what you want is a configuration file format. There are 
already many config file formats, as well as many textual data formats. 
YAML comes to mind. This looks like YAML (certainly, a subset of it) a 
lot more than JSON or even JavaScript.

Why not just embed completely valid JSON items in the configuration file 
format of your choice? That seems a lot more practical. Configuration 
files usually say "name=value" anyway, not "name: value".

# is not comment syntax in JSON, or JavaScript. It's from config files 
and scripts. Hence demonstrating that this is not really JSON-related.

You say "omit braces for the root object", but then it's not JSON. If 
you include the braces, then it's JSON, and it's annoying for humans to 
write. Humans are lazy and don't like to balance < > tags or { } braces. 
They like line breaks by hitting Enter to separate things. But line 
breaks are not separators in JSON/JavaScript. JSON/JS are designed to 
let the author put in line breaks wherever he/she/it wants, to aesthetic 
taste. And vice-versa for commas. It's easy to balance { } braces when 
you just have a couple of them, i.e., a simple JSON object that is the 
single value of a single config element on a single line.

Your format should not get a media type. If it is for "humans", it needs 
to be text/*, such as text/plain. Humans edit things with editors, that 
work on text. As text, you cannot assume UTF-8 encoding. It's just a 
stream of text. If a user chooses to author this format in Shift-JIS (or 
if that's the locale/code page in effect on the local machine), that's 
the user's choice. You cannot ignore the implications of the charset 
parameter.

Finally, since the draft explicitly disavows use in transfer protocols 
and so forth, it's not appropriate for Standards Track. I'd suggest 
Experimental.

Regards,

Sean