It's an oversight, but does it really matter anywhere? YAML can be used for a JSON-y syntax that allows comments, which is good enough for most use cases.
JSON isn't semantic so there is no need to put __ before comment, it's not like it's meta or something. It will still be parsed and processed by the JSON parser, which is a waste of computer cycle.
It's kind of a future-proofing thing. If you put a field called "comment" in a JSON blob, especially one in a format you don't control, you run the risk that future versions of the format will define the "comment" field and give it actual meaning. A crazy prefix makes this at least slightly less likely.
They were removed because people started trying to use them to hold additional parsing directives and other meta-information which would have destroyed interoperability and defeated the entire purpose of a simple interchange format. See: https://groups.yahoo.com/neo/groups/json/conversations/topic...
If you want to annotate JSON in documentation, I say "go ahead and just use //". Any programmer reading it will understand that those lines are taken to be comments and they shouldn't type them in their final request.
But this too has significant whitespace, acting as a comma in separating properties. (It's not clear whether you can mix commas and whitespace here.)
Also this claims to not need escapes, but it's also not clear how this format handles a comma or a newline in strings without escaping, do they act as a comma to separate properties or do they act as natural commas/newlines?
HJSON isn't exactly a nicely compact spec I'd want to use in data exchange either. For local configuration files and the likes, where you want comments etc., it doesn't really matter how big the spec is.
If you haven't read the JSON spec and you use JSON I recommend doing so. It takes five minutes. My personal favorite line: "Because it is so simple, it is not expected that the JSON grammar will ever change."
Also, they're probably right. I mean JSON isn't pretty, but its easy. Why should I use YAML for prettier config files, when the people looking into those files are all technical anyway.
JSON plus comments and python-style multi-line strings is great.
The thing where you can leave quotes off strings makes me nervous, especially the example where the value is HTML with its own embedded double quotes for attribute values.
Not requiring quotes on strings like that looks like an obvious vector for injection attacks. I guess Hjson isn't designed to be generated automatically, but I'd prefer a format that is easy to generate safely.
What I really want is JSON plus comments plus multi-line strings plus relaxed rules on trailing commas... While maintaining as simple and unambiguous a parsing model as possible.
i've used json5 since the beginning. it's great! just a couple week ago they merged in descriptive error messages too. No more wondering where the bug is!
Strings without quotes leads to all kinds of trouble in YAML. You end up just quoting everything anyway the first time you need to use "false" or "[some words here]" as a string.
Unquoted strings are valid in yaml just like this format. There are at least 2 ways to specify a list of things. There are some super bizarre looking possible formats for lists of mapping types.
There are a number of others given the length of the spec. Yaml is a complicated beast that generally has more than one way to do any given thing
Okay, does anyone actually believe that causes a problem?
I can think of ONE time when that causes a problem, and that's with indentation with multi-line strings. Oh look, HJSON included that feature. That's like throwing the baby out and keeping all the bathwater.
I can't find a specific example off the top of my head but I'll say I've been managing a Jekyll site for a while now and whitespace errors in frontmatter and data files cause all kinds of problems. I'm not sure I could explain the details but it's a legit criticism of YAML. IMO part of the problem is that YAML looks very straightfowrard and is until it suddenly isn't. Whitespace is part of that problem.
As an anecdote on the flip side, I've been building Middleman sites for a while now and can't remember ever having an issue with whitespace in the front matter or local data.
YAML is more complex that most people tend to realize. (This was brought up in a 2011 discussion about possibly standardizing a metadata section for Markdown documents which sadly went nowhere. [1])
Take a look at example 2.11 in the YAML spec [2], for example, and see if you can make heads or tails of it.
You don't need most of those features. A pared down YAML with the cruft removed (implicit typing, flow style, tag tokens, node anchor & references) is actually pretty simple as well as less "gotcha-y".
I came here to make the same comment. The ability to leave off quotes on strings is a misfeature which overly complicates the language. Also I see no need for three different comment styles.
That might work for programming languages (C++'s bad rep nonwithstanding), but for data exchange formats you cannot cherrypick features, you have to support the whole spec, and nothing else.
I think it's more nuanced than that. You must be strict in what you emit, but can be liberal in what you accept. That liberalness can go too far though, and should not make parsing brittle, or encourage misuse of the spec. It's there more to allow someone's unambiguous mistakes to still parse.
- Accidentally left in a final comma on a list? That's okay, that only means one thing, we understand.
- Allow non-quoted keys on objects? Well, we understand JavaScript generally allows this, so we'll let it slide. This time.
- Make newline significant and define new items? Okay, are we just ignoring space efficient payloads now? Should making it space efficient mean changing formats from Hjson to json?
- Considering all terms in place of a object value a string until a newline? Are you just trolling me now? How is that more human readable? Does your spoken language not use quotes to distinguish distinct chunks of communication or something, and if so, does it use a Latin alphabet so it's off-putting when you see them?
Needless to say, I'm really confused by the reason this even exists.
I think the problem it is solving is that JSON is designed and best used as a data exchange format, but it also gets used for configuration files, which it does okay with but is not really so good. INI files don't have a clear standard. YAML is too complicated, and using turing complete javascript for configuration seems like you've just gone too far.
we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.
> we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.
Using JSON for configuration is just the whole situation of using XML for data exchange redux. One of the major points for JSON over XML for data exchange was that it was so much better because it was optimized for data, not markup. Why are we ignoring this argument now that JSON is on the other side? JSON is used for configuration because it's ubiquitous, not because it fits the problem domain well. Let's just choose a more appropriate format.
Choosing the most common set of rules for INI files (what is proposed by Wikipedia[1] is probably sufficient) would serve us MUCH better than coaxing a data interchange format into that role.
well basically virtually anything other than JSON that's actually designed to be configuration would be better for configuration. There's dozens of them. that is the problem: JSON parsers and generators are ubiquitous in the way that no single configuration format is. Right now, I can just use json in any language and get data between any language and any other language. If I use it for config I get the advantage of even being able to config across multiple languages that might be getting used in a single system if I have to. No proper configuration format has that level of mindshare and interoperation.
If you're using a strongly typed language, XML even has one (IMO) massive advantage over JSON: You can use XSD to define a schema declaratively. This means you get
(1) lots of general tooling support, in particular you get at least decent editor support for your config file, and
(2) you can autogenerate the code needed to read your configuration into structured data without having to do any unnecessary duplication of "key names" (tags) as you have to with e.g. INI or JSON. You also get the data sturctures themselves for "free" (based on the XSD).
Alright, it's not the end of the world to not have these things, but they're both very nice to have.
Yes indeed I have, and I have several problems with it, one of which is "Expires: August 3, 2013" with no new version in sight. My other major problem is that AFAICT it doesn't support one of my pet favorite features namely "Algebraic Data Types"[0, 1]. If you extend json-schema like Swagger has done it might support ADTs properly AFAICT, but I don't have any actual practical experience with Swagger.
[0] https://en.wikipedia.org/wiki/Algebraic_data_type
[1] I should note that support for ADTs in XSD is sometimes sketchy in the various code generators, but at least the XSD specification supports it. (It could also be argued that XSD supports something even more general... which it probably shouldn't since ADTs basically cover the whole data structure space unless you go to higher kinds, inheritance and such.)
While I agree on some points, I do not agree in general. I think too much prescriptivism in protocol implementation is a naive approach, and assumes that we can always get things right initially. Sometimes real-world concerns and needs drive changes, not just sloppiness.
Well, the first thing I thought of is what nightmare would it be to safely implement a parser for this in C. I filed a Github issue for this one: https://github.com/laktak/hjson/issues/37
Yes! There is the same ambiguity in Yaml, so syntax highlighters of the format don't agree where a string ends...
The site even has an ambiguous example:
three: 4 # oops
Well, is that "4 # oops" or 4?
I saw no rule about ending comments, and they say that
three: 3 times
is a string.
I have seen no formal specification of the grammar, so we already have lot of ambiguity. Good luck to implementers...
Seriously, removing the "no quotes needed" rule would improve greatly the format. If you want to include HTML with double quotes literally, just use the multiline string format and be done.
> When you omit quotes the string ends at the newline.
> Preceding and trailing whitespace is ignored as are escapes.
>
> A value that is a number, true, false or null in JSON is
> parsed as a value. E.g. 3 is a valid number while 3 times is
> a string.
The problem is that this is supposed to be a more-easily-readable form of JSON, but it requires consulting the docs to understand the meaning of something which is completely unambiguous in regular JSON.
It is ambiguous only if you think it can be a completely useless format. If you decide to use it, chances are you considered it useful, and the only useful way this can parse is as a number, otherwise it would't be able to represent numbers, booleans and null. I'd say it parses pretty much as expected, and as such, contrary to other comments, you don't have to go back to the docs every so often.
While I have been hoping for "JSON plus comments" to be a real and common thing for quite a while now, one of the strengths of JSON is right there on json.org. See it? A set of five simple syntax diagrams that entirely and virtually unambiguously define the json syntax.
It’s tough to know when to stop when simplifying a syntax. (For an extreme example, see Stylus, which was like Sass but so extreme that mixins and properties became ambiguous for each other.) I, too, would like to see the return of quotes for string values, for increased clarity.
Primary goals were to remove as much syntax as possible and make it play well with line-based diffs (with the hopes that someone who knows knowing about the language could resolve conflicts without getting tripped up by surrounding quotes, trailing comments, etc).
Unfortunately, conflicts in white-space based languages can get even worse than regular conflicts because you have very few visual structural "anchors" to start to gain an understanding of the conflict. (If you have to resolve manually, that is.)
Granted, if the number of conflicts which cannot be automatically resolved is reduced by enough, then it might not matter in the grand scheme of things. However, I'd be worried that this would make "accidental" automatic resolution of semantic conflicts more common. That may be an unfounded/irrational fear, I don't know.
> The thing where you can leave quotes off strings makes me nervous, especially the example where the value is HTML with its own embedded double quotes for attribute values.
Learn from Perl. The quote operator is your friend (and I frequently lament it's omission in Bash). You could simplify it by not using the matching enclusures ({ and }, [ and ], etc). It's easy to parse. and if you keep the quoting character somewhat rare, it's not hard to read.
I haven't used Perl in quite some time, and this is the sort of thing is why it was bad. Quotes are quotes are quotes in almost every language. It's completely unambiguous, the downside is that you sometimes need to escape them.
This, on the other hand, is a 'solution' to escaping quotes that is completely mad. Using non-standard quotes, especially mixing and matching them is a disaster for readability and maintainability (using a T in your string now? need to change the quotes!). Triple quotes are just find if you want to avoid escapes, and hjson seems to support them.
> Quotes are quotes are quotes in almost every language. It's completely unambiguous
Oh, like in C and C++ where single quotes denote a char, and double quotes a string?
Or in Perl, PHP and Ruby where double quotes interpolate, and single quotes don't?
Or in JavaScript and Python, where there's no functional difference between single and double quotes?
Or C#'s string literals which only support double quotes, but you prefix the string with @ to denote it's verbatim?
Or systems that allow repeated double quotes within a double quote string literal to stand in for an escape ("foo ""bar"" baz"), as many SQL systems do?
Or what about systems that interpolate, and the differences between what they do and do not interpolate? Variables? Escape characters? Hexadecimal escapes?
You're fooling yourself if you think it unambiguous in anything except for the language you are dealing with, and if you're within that language, who cares what you use as long as it's consistent? You learn it, and then it's unambiguous (if implemented well).
This is no different than if your language supports hex numbers (usually done through prefixing it with 0x). Those are two different ways to specify the exact same thing (a binary number!). The benefit comes from using it in the circumstance where it's appropriate. That is, where it enhances readability, not where it detracts from it.
> This, on the other hand, is a 'solution' to escaping quotes that is completely mad. Using non-standard quotes, especially mixing and matching them is a disaster for readability and maintainability
because I think it's clearer, and learning once that a literal q defines a new quote operator that is in effect until it's next seen is simple, easy to remember, and yields very useful readability gains.
> using a T in your string now? need to change the quotes!
I included the qTT example just to show how it worked, not to endorse its use. I thought that would have been obvious from my statement "You could simplify it by not using the matching enclosures ({ and }, [ and ], etc). It's easy to parse. and if you keep the quoting character somewhat rare, it's not hard to read."
In any case, I fail to see how how that's a problem beyond any other quote character. Including that character in your string will result in a compile time error in all but the most esoteric of cases, making it easy to find.
> This, on the other hand, is a 'solution' to escaping quotes that is completely mad.
Meh, Perl's solution is fine. You can throw up your hands and say it's crazy, but as a person who worked with Perl for 20 years, I've never had the problem you describe. I tend not to use the qq() or q() style quotes, but I've used s@@@ and s,,, so many times I can't count. It's really quite nice (and perfectly readable unless you do something weird like 'sxxx'.
I like that you can leave the quotes off of keys, which should always parse as identifiers. (And those that don't should require quotes.) Leaving the quotes of values seems like the problem.
Do checkout http://json5.org/ based off the original JSON author Doug Crockford's own proposed parser extensions, primarily trailing commas and comments, both of which have been a point of contention pretty much the day since the day JSON landed. It's a much simpler and saner proposal.
Trailing commas and JSON comments are are already supported in the newer browsers (try the Chrome console for instance).
Fortunately quoteless strings or optional-commas/newline-separator as proposed in Hjson will never fly. They are brittle and ambiguous. Who knows what will this get parsed as:
{
a: hello's and hi's have
'misplaced' apostrophes
b: ball: a round # and # bouncy object
c: cakes and
candy: both have sugar
# but how do I include a hash at the start of a multiline-unquoted string?
}
Javascript object literals != JSON. JSON is a restricted subset of JS object literals (and not actually a strict subset: a JSON string can contain unescaped U+2028 "LINE SEPARATOR" and U+2029 "PARAGRAPH SEPARATOR" codepoints, a Javascript string can not)
This spec repeats one of the problems with using YAML as a configuration spec. To quote: "if your key includes a JSON control character like {}[],: or space, use quotes
if your string starts with { or [, use quotes"
JSON and YAML are interchange formats, not configuration formats. Rather than than hacking up an interchange format, it's probably better to use something designed for configuration formats, like TOML.
JSON is an interchange format, but YAML is pretty obviously meant for configuration, given the huge emphasis on human readability and editing.
As for TOML, it's a good replacement for mostly-flat INI-style files but the syntax is really awkward for the kinds of places you'd normally use YAML, especially nesting lists/maps.
"Both HOCON and YAML make the mistake of implementing too many features (like anchors, sustitutions or concatenation)"
YMMV, but if you're aiming for a format that's edited / maintained by humans things like YAML's anchors and substitution are exactly the features I'd want...
Just the other day I commented complaining about JSON config files without comments, but now here I am complaining about _three_ ways to write a comment. OK, I can see two ways: block and line comments. But why two ways to write line comments? Why start off a new grammar with that added complexity?
You mean why bother having multiple ways to comment?
Well, I sometimes use both C-style (/* ... */) and C++-style (// ...) comments in the same file to sort of mark the relative importance of comments. But yeah, I guess that's not strictly necessary, I could do without.
I also notice everyone seems to keep silent about the fact that comments were intentionally left out of the final JSON specification to avoid abuse by parsers/vendors.
Comments would be nice but it is also nice to keep JSON pure and simple. There are some other json formats that use comments like jsoncpp but really not needed.
But, if comments really are needed, another easy way to have comments is have a file that rides to the side of any json files or docs. Sometimes we use a markdown/text file next file.json -> file.json.md / file.json.txt to describe overall or a file.meta.json that has comments per key. This is only needed sometimes for physical files. If json is from the server, commenting can be done there or in docs if needed.
The notion that comments are neither simple nor really necessary is completely bonkers to me, or anyone else who has implemented a lexer or tried to debug an undocumented config file.
Why do you need ECMAScript syntax? It's not like you're going to directly feed a json file into a JS interpreter. Well, not unless you have a death wish.
Because it's a syntax that needs no extra explanation.
It's not a superset, so no extra add-on features need extra doc, and it's less of a subset then JSON so the rules of what's disallowed are much simpler.
And yet again no date format. Am I the only person who is ever inconvenienced by this? It seems like it's so obviously the most glaring flaw with JSON that I'm surprised nobody wants to fix it.
Sure, that would be fine. They could also use a totally wacky format, I don't care. The problem is that without a standard the JSON tools in different languages don't all agree on how to serialize dates and you end up needing to deserialize/serialize manually the smooth over the differences. The problem isn't that you can't represent dates; it's that there is no standard way to do it.
That's not "standard." That's one of many ways that people represent dates in JSON, because the JSON specification itself does not mandate that you use any particular representation. If you use it there is no guarantee it will be recognized as a date on the other end.
What black hole are you sending JSON into where the only way they could know something is a date is if you use a date type? Why can't that be part of the data structure you agreed upon in order to communicate in the first place?
Even if there is an agreed on schema, parsers can generate native Date objects on the recipient if there is a date type. When you deserialize a nested graph of objects, it's hard to convert each date to an actual date if what you get is just a string. Makes it a lot easier during integration.
Why am I hand-writing code to supplement the parser? I mean, hell, we don't need JSON at all, why don't I just invent my own serialization format and write parsers for it in each environment I want to use it in.
Well, it'd need to cover dates, times with time zones, date times with time zones, times without time zones, date times without time zones. Seems better pegged to the data source without thinking it out clearly.
Yeah, I guess, but everyone ends up implementing it anyway; the problem is they all do it in an idiosyncratic way (and one that is ambiguous... after all, maybe I really wanted that to be a string).
I have a (big) .NET project that uses multiple libraries one of them being Akka.NET which uses HOCON. Being honest, it felt completely awkward to use it in this respect (a little corner in the project that uses that different HOCON thing).
This abandons a lot of principles of JSON that are there to avoid ambiguous situations. The small benefits don't seem to outweigh the snake pit you're jumping into.
Rigidity and consistency are not always bad things. They can help prevent bugs, security vulnerabilities, and they drastically reduce complexity of implementation.
JSON might often be too rigid, but I think it's important to note that "easier" (in that you don't need to learn the syntax) isn't always better.
This "easier" format is actually more "complex". JSON can be described with just a couple of simple rules (http://json.org/ ), while this format adds many new rules (e.g. for doing same things in multiple ways). The more rules you have, the more things you have to remember, the harder it is to find the reason of the problem.
BTW. it is very simple to do comments in JSON :) You can just add
"comment1" : "This is my comment",
to any object, it will be ignored by software that processes your file.
I don't, actually, I use preprocessors too¹, but since they're not always an option, I'd rather recommend yaml than have yet another pointless config file language needlessly fragment the market.
We've been looking for a replacement configuration format over our ancient ini files and had rejected JSON for TOML because TOML allows comments (and man, can comments be useful in configuration files). This looks like a nice medium-long term alternative.
I'll agree with that, but what is the use case for giving this to non-developers? Everything on this page looks like it's directed towards making JSON files slightly simpler for programmers.
Your argument is a layman can't puzzle out JSON easily, but do you think hjson is any better? Syntactically it's core seems to just be QOL improvements over writing JSON by hand. It isn't any more intuitive from my perspective. In fact, in many cases it seems less intuitive by offering a greater number of ways to do the same thing.
I'm not using a nonstandard JSON extension unless it implements a standard freaking date format. I also don't think bare strings are necessarily a great idea since they lose implicit type information.
- People start adding features to fix annoying things with the format, add support for binary data, comments, schemas, add more metadata etc..
- Many versions proliferate, people start writing converters and verifiers
- A standards committee is formed and write an 800 page spec and 80kloc reference implementation
- Eighteen different libraries wrap or reimplement the reference implementation
- Someone gets fed up with this nonsense and converts their app to save their data in a new simple text format.
- The circle of life continues.
I love this idea and wish json had comments, too, but if you start hitting the point where JSON is not expressive or fluid enough, that's a hint that it's probably not the right thing for what you're doing. This variant puts a lot of work into human-friendly json, but if you're doing a lot of hand-editing of a file, it should probably not be JSON.
> Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.
And now you can't roundtrip the comments if for some reason your JSON parser needs to change something.
222 comments
[ 2.1 ms ] story [ 233 ms ] threadHN discussion: https://news.ycombinator.com/item?id=3912149
If you want to annotate JSON in documentation, I say "go ahead and just use //". Any programmer reading it will understand that those lines are taken to be comments and they shouldn't type them in their final request.
> Both HOCON and YAML make the mistake of implementing too many features (like anchors, sustitutions or concatenation).
Also this claims to not need escapes, but it's also not clear how this format handles a comma or a newline in strings without escaping, do they act as a comma to separate properties or do they act as natural commas/newlines?
{
}Parses to "one," because it is a quoteless string?
What about true and false, is false the boolean constant or a unquoted string "false".
That's why I remove those features.
Significant whitespace is a normal complaint for beginners in python too, but most people prefer it in the end.
I like how nice config files can look with YAML and JSON being a subset of it makes it even more convenient
JSON spec: http://www.ecma-international.org/publications/files/ECMA-ST...
If you haven't read the JSON spec and you use JSON I recommend doing so. It takes five minutes. My personal favorite line: "Because it is so simple, it is not expected that the JSON grammar will ever change."
Also, they're probably right. I mean JSON isn't pretty, but its easy. Why should I use YAML for prettier config files, when the people looking into those files are all technical anyway.
The thing where you can leave quotes off strings makes me nervous, especially the example where the value is HTML with its own embedded double quotes for attribute values.
Not requiring quotes on strings like that looks like an obvious vector for injection attacks. I guess Hjson isn't designed to be generated automatically, but I'd prefer a format that is easy to generate safely.
What I really want is JSON plus comments plus multi-line strings plus relaxed rules on trailing commas... While maintaining as simple and unambiguous a parsing model as possible.
> Numbers can include Infinity, -Infinity, NaN, and -NaN.
E.g.
http://www.yaml.org/start.html
There are a number of others given the length of the spec. Yaml is a complicated beast that generally has more than one way to do any given thing
"YAML expresses structure through whitespace. Significant whitespace is a common source of mistakes that we shouldn't have to deal with."
I can think of ONE time when that causes a problem, and that's with indentation with multi-line strings. Oh look, HJSON included that feature. That's like throwing the baby out and keeping all the bathwater.
Although admittedly I haven't had to work with YAML a lot but I have liked it when i've touched it.
Take a look at example 2.11 in the YAML spec [2], for example, and see if you can make heads or tails of it.
[1]: https://pairlist6.pair.net/pipermail/markdown-discuss/2011-A...
[2]: http://www.yaml.org/spec/1.2/spec.html#id2760395
At least perl doesn't support this, so it's inherently insecure there, but you can always use YAML::Syck which didn't go this way.
(and pyYAML itself can't always parse its own output correctly...)
- Accidentally left in a final comma on a list? That's okay, that only means one thing, we understand.
- Allow non-quoted keys on objects? Well, we understand JavaScript generally allows this, so we'll let it slide. This time.
- Make newline significant and define new items? Okay, are we just ignoring space efficient payloads now? Should making it space efficient mean changing formats from Hjson to json?
- Considering all terms in place of a object value a string until a newline? Are you just trolling me now? How is that more human readable? Does your spoken language not use quotes to distinguish distinct chunks of communication or something, and if so, does it use a Latin alphabet so it's off-putting when you see them?
Needless to say, I'm really confused by the reason this even exists.
we just need JSON, but with a couple things fixed up to make it nicer to use for configuration files.
Using JSON for configuration is just the whole situation of using XML for data exchange redux. One of the major points for JSON over XML for data exchange was that it was so much better because it was optimized for data, not markup. Why are we ignoring this argument now that JSON is on the other side? JSON is used for configuration because it's ubiquitous, not because it fits the problem domain well. Let's just choose a more appropriate format.
Choosing the most common set of rules for INI files (what is proposed by Wikipedia[1] is probably sufficient) would serve us MUCH better than coaxing a data interchange format into that role.
1: https://en.wikipedia.org/wiki/INI_file
(1) lots of general tooling support, in particular you get at least decent editor support for your config file, and
(2) you can autogenerate the code needed to read your configuration into structured data without having to do any unnecessary duplication of "key names" (tags) as you have to with e.g. INI or JSON. You also get the data sturctures themselves for "free" (based on the XSD).
Alright, it's not the end of the world to not have these things, but they're both very nice to have.
[0] https://en.wikipedia.org/wiki/Algebraic_data_type [1] I should note that support for ADTs in XSD is sometimes sketchy in the various code generators, but at least the XSD specification supports it. (It could also be argued that XSD supports something even more general... which it probably shouldn't since ADTs basically cover the whole data structure space unless you go to higher kinds, inheritance and such.)
[1]: https://github.com/edn-format/edn
The site even has an ambiguous example: three: 4 # oops Well, is that "4 # oops" or 4? I saw no rule about ending comments, and they say that three: 3 times is a string.
I have seen no formal specification of the grammar, so we already have lot of ambiguity. Good luck to implementers...
Seriously, removing the "no quotes needed" rule would improve greatly the format. If you want to include HTML with double quotes literally, just use the multiline string format and be done.
The first time, and the second time if you haven't looked at it in a month, and a third time a month after that. And so on.
While I have been hoping for "JSON plus comments" to be a real and common thing for quite a while now, one of the strengths of JSON is right there on json.org. See it? A set of five simple syntax diagrams that entirely and virtually unambiguously define the json syntax.
It’s tough to know when to stop when simplifying a syntax. (For an extreme example, see Stylus, which was like Sass but so extreme that mixins and properties became ambiguous for each other.) I, too, would like to see the return of quotes for string values, for increased clarity.
Primary goals were to remove as much syntax as possible and make it play well with line-based diffs (with the hopes that someone who knows knowing about the language could resolve conflicts without getting tripped up by surrounding quotes, trailing comments, etc).
Granted, if the number of conflicts which cannot be automatically resolved is reduced by enough, then it might not matter in the grand scheme of things. However, I'd be worried that this would make "accidental" automatic resolution of semantic conflicts more common. That may be an unfounded/irrational fear, I don't know.
Learn from Perl. The quote operator is your friend (and I frequently lament it's omission in Bash). You could simplify it by not using the matching enclusures ({ and }, [ and ], etc). It's easy to parse. and if you keep the quoting character somewhat rare, it's not hard to read.
E.g.
Edit: To be clear, I wish JavaScript had a quote operator, and JSON started with it. :/1: http://perldoc.perl.org/perlop.html#Quote-and-Quote-like-Ope...
This, on the other hand, is a 'solution' to escaping quotes that is completely mad. Using non-standard quotes, especially mixing and matching them is a disaster for readability and maintainability (using a T in your string now? need to change the quotes!). Triple quotes are just find if you want to avoid escapes, and hjson seems to support them.
Oh, like in C and C++ where single quotes denote a char, and double quotes a string?
Or in Perl, PHP and Ruby where double quotes interpolate, and single quotes don't?
Or in JavaScript and Python, where there's no functional difference between single and double quotes?
Or C#'s string literals which only support double quotes, but you prefix the string with @ to denote it's verbatim?
Or systems that allow repeated double quotes within a double quote string literal to stand in for an escape ("foo ""bar"" baz"), as many SQL systems do?
Or what about systems that interpolate, and the differences between what they do and do not interpolate? Variables? Escape characters? Hexadecimal escapes?
You're fooling yourself if you think it unambiguous in anything except for the language you are dealing with, and if you're within that language, who cares what you use as long as it's consistent? You learn it, and then it's unambiguous (if implemented well).
This is no different than if your language supports hex numbers (usually done through prefixing it with 0x). Those are two different ways to specify the exact same thing (a binary number!). The benefit comes from using it in the circumstance where it's appropriate. That is, where it enhances readability, not where it detracts from it.
> This, on the other hand, is a 'solution' to escaping quotes that is completely mad. Using non-standard quotes, especially mixing and matching them is a disaster for readability and maintainability
Maybe you think
is fine, or you may prefer (if your language supports it).I prefer
because I think it's clearer, and learning once that a literal q defines a new quote operator that is in effect until it's next seen is simple, easy to remember, and yields very useful readability gains.> using a T in your string now? need to change the quotes!
I included the qTT example just to show how it worked, not to endorse its use. I thought that would have been obvious from my statement "You could simplify it by not using the matching enclosures ({ and }, [ and ], etc). It's easy to parse. and if you keep the quoting character somewhat rare, it's not hard to read."
In any case, I fail to see how how that's a problem beyond any other quote character. Including that character in your string will result in a compile time error in all but the most esoteric of cases, making it easy to find.
Meh, Perl's solution is fine. You can throw up your hands and say it's crazy, but as a person who worked with Perl for 20 years, I've never had the problem you describe. I tend not to use the qq() or q() style quotes, but I've used s@@@ and s,,, so many times I can't count. It's really quite nice (and perfectly readable unless you do something weird like 'sxxx'.
Trailing commas and JSON comments are are already supported in the newer browsers (try the Chrome console for instance).
Fortunately quoteless strings or optional-commas/newline-separator as proposed in Hjson will never fly. They are brittle and ambiguous. Who knows what will this get parsed as:
Version 49.0.2623.112 (64-bit)
Javascript object literals != JSON. JSON is a restricted subset of JS object literals (and not actually a strict subset: a JSON string can contain unescaped U+2028 "LINE SEPARATOR" and U+2029 "PARAGRAPH SEPARATOR" codepoints, a Javascript string can not)JSON and YAML are interchange formats, not configuration formats. Rather than than hacking up an interchange format, it's probably better to use something designed for configuration formats, like TOML.
As for TOML, it's a good replacement for mostly-flat INI-style files but the syntax is really awkward for the kinds of places you'd normally use YAML, especially nesting lists/maps.
What It Is: YAML is a human friendly data serialization standard for all programming languages.
YMMV, but if you're aiming for a format that's edited / maintained by humans things like YAML's anchors and substitution are exactly the features I'd want...
Well, I sometimes use both C-style (/* ... */) and C++-style (// ...) comments in the same file to sort of mark the relative importance of comments. But yeah, I guess that's not strictly necessary, I could do without.
But, if comments really are needed, another easy way to have comments is have a file that rides to the side of any json files or docs. Sometimes we use a markdown/text file next file.json -> file.json.md / file.json.txt to describe overall or a file.meta.json that has comments per key. This is only needed sometimes for physical files. If json is from the server, commenting can be done there or in docs if needed.
- https://github.com/bevry/cson
- https://github.com/groupon/cson-parser
[0]: http://json5.org/
It's not a superset, so no extra add-on features need extra doc, and it's less of a subset then JSON so the rules of what's disallowed are much simpler.
ISO 8601?
But I'm a scala developer so I might be biased.
JSON might often be too rigid, but I think it's important to note that "easier" (in that you don't need to learn the syntax) isn't always better.
For an interchange format, JSON does the job very well. Small, simple, human readable, easy to implement.
For a configuration format, JSON leaves a lot to be desired. It's almost there, but has enough warts to be annoying.
You're not going to get a one-size-fits-all format.
BTW. it is very simple to do comments in JSON :) You can just add "comment1" : "This is my comment", to any object, it will be ignored by software that processes your file.
A new spec that just addressed those alone would be great.
I'm quite happy using a preprocessor like [0], which keeps the great simplicity of JSON and just allows comments.
[0] https://www.npmjs.com/package/strip-json-comments
I don't, actually, I use preprocessors too¹, but since they're not always an option, I'd rather recommend yaml than have yet another pointless config file language needlessly fragment the market.
¹: Thankfully it's rather trivial in python: https://github.com/creshal/yspave/blob/master/yspave/pave.py...
For me the biggest problem with JSON is lack of full floating point support, i.e. NaN, +-Infinity, -0.
The only reason JSON is popular is because of Javascript. And the only reason Javascript is popular is because of the browsers and their history.
We've been looking for a replacement configuration format over our ancient ini files and had rejected JSON for TOML because TOML allows comments (and man, can comments be useful in configuration files). This looks like a nice medium-long term alternative.
If you showed JSON to someone on the street they could probably understand the gist of it (if pretty printed). Good luck asking them to write it.
[1]: https://news.ycombinator.com/item?id=11501332
[1]: https://github.com/honey/honey
- It works great, lots of people start using it
- People start adding features to fix annoying things with the format, add support for binary data, comments, schemas, add more metadata etc..
- Many versions proliferate, people start writing converters and verifiers
- A standards committee is formed and write an 800 page spec and 80kloc reference implementation
- Eighteen different libraries wrap or reimplement the reference implementation
- Someone gets fed up with this nonsense and converts their app to save their data in a new simple text format.
- The circle of life continues.
I love this idea and wish json had comments, too, but if you start hitting the point where JSON is not expressive or fluid enough, that's a hint that it's probably not the right thing for what you're doing. This variant puts a lot of work into human-friendly json, but if you're doing a lot of hand-editing of a file, it should probably not be JSON.
[1] http://www.cleancss.com/json-editor/
And now you can't roundtrip the comments if for some reason your JSON parser needs to change something.