Re: [Json] Human JSON (Hjson)

[Christian Zangl <[e-mail]>]

On 2016-05-25 08:48, Sean Leonard wrote:
> 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.

Yes this is another config file format. Why? Because I think that using 
JSON for configs is an antipattern. Since YAML&others are not a good 
option (to some people) Hjson is positioned as a reasonable alternative.

> 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".

I'm not sure what you mean here. If I embed JSON in the config I have 
the same problems as using JSON for configs in the first place.

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

JSON was 'discovered' in JavaScript, hence it's name, but has since been 
ported to 50+ languages. While JavaScript is evolving, JSON is fixed at 
v1 (not a bad thing). So to me, apart from the name, JSON isn't 
JavaScript anymore.

JSON doesn't allow comments so selecting # seemed practical (IMO it's 
nicer to read than //). // and /**/ comments were added because it was a 
popular request.

> 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.

Hjson is a superset of JSON. You don't have to omit them but they are 
optional for the root.

You need something to define the structure. Braces are there because 
JSON has them and because the alternatives (like indentation) seem worse.

Hjson allows line breaks to be separators instead of commas.

> 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.

I can remove the media type but wouldn't it help with file 
associations/editor syntax?

Joe suggested to require UTF-8, it made sense to me. 
https://github.com/laktak/hjson/issues/43

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

OK. Thanks for the feedback!