5 ms·

I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5)

I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. JSON6 proposal [1] supports all of this, except (4). Unfortunately it also supports more and make the spec a bit too complex for my taste (JSON has a compact spec; any extension should honor this). Same issue with JSON5 proposal [2]. EKON [3] is certainly the best candidate. However, it didn't get any traction. [1] https://github.com/d3x0r/JSON6 https://github.com/d3x0r/JSON6 [2] https://json5.org/ https://json5.org/ [3] https://github.com/ekon-org/ekon https://github.com/ekon-org/ekon

4ad 3y ago
Among types and other useful properties, CUE supports everything you asked for. We're even considering adding a "data-only" mode to CUE which would be exactly what you asked for. https://cuelang.org https://cuelang.org
- conaclos 3y ago
  Is there any concise representation of the language spec? Similar to the spec of JSON [1]. [1] https://www.json.org/json-en.html https://www.json.org/json-en.html
  - 4ad 3y ago
    No, we do have a spec[1], but it cannot be as concise as the JSON link posted because the JSON link is mostly only about syntax, and our spec discusses both syntax and semantics. And of course, we are a much richer language than JSON, with many more features and computational behavior. That being said, it would be nice to use railroad diagrams to describe syntax in our spec. [1] https://cuelang.org/docs/references/spec https://cuelang.org/docs/references/spec
codeflo 3y ago
JSON as a computer-generated serialization format doesn't need any of those features. But for human-written configuration files, at the very least trailing commas and comments are basically a necessity. The question then is which features to pick beyond that (in my humble opinion, none), and how such a new standard would gain traction. JSON5, JSON6, JSONC all basically attempt to solve the latter problem by branding, but so far, mostly have failed. It doesn't help that there's an insane amount of bike-shedding going on in this space. The people who have forked JSON5 to create JSON6 for example have created an endless amount of confusion over which standard to use, harming both of them. I think they might want to think really hard whether the inclusion of octal literals was really worth the hostile fork.
chrismorgan 3y ago
I strongly dislike the idea of optional {} on the root object. It’s weird special-casing that adds complexity (code and cognitive) for no adequate reason, destroying the neat contextless recursion of parsing. Remember also that objects aren’t the only valid JSON values; and why should objects be privileged over, say, arrays? You could make [] optional too without introducing actual grammatical ambiguity, other than deciding what to do about the empty string (which “optional {} on the root object” would make valid, unless you special-case it further). But all of these cases require that humans and computers alike look ahead, rather than seeing { and immediately knowing what they’re dealing with.
- elondaits 3y ago
  Arrays at the root of JSON are dangerous and best avoided: https://stackoverflow.com/questions/3503102/what-are-top-level-json-arrays-and-why-are-they-a-security-risk https://stackoverflow.com/questions/3503102/what-are-top-lev...
  - chrismorgan 3y ago
    The matter of literals being interceptable due to using the current value of globals like Array was fixed across the board over a decade ago. You don’t need to worry about it in the slightest. (Exploits also depended on a form of cross-site request forgery that (a) has been well-understood and avoided for fifteen years now (and with a perfect solution available for five years via the SameSite cookie attribute), so if you’re affected you very probably messed up in other exploitable ways too, and (b) is often even protected by default now: Chromium switched the default to SameSite=Lax in early 2020, so the sensitive cookie would need to be explicitly set with SameSite=None in order to be vulnerable at all. Safari and Firefox haven’t yet shipped this behaviour, though they all agree they want to, since it does break some older sites.)
  - tadfisher 3y ago
    In the decade (or more?) since that was a problem, ES added JSON.stringify(). Nobody runs eval() to parse JSON anymore, and moreover, the root cause of the exploit (CSRF) has been addressed with CORS and sane default browser policy.
kayodelycaon 3y ago
Let me introduce you to our lord and savior: YAML. ;)
- _ZeD_ 3y ago
  Yaml is plain unreadable for me tho
- hyperhopper 3y ago
  Ah yes, the language where a string can magically become a boolean and cause an error. And you can never be sure what is legal because of so many changes in parsing legality between versions. Yaml is one of the worst config languages.
  - FireInsight 3y ago
    YAML is great except for everything wrong with it, YAML is the worst except for all the others, etc., etc.
  - rgovostes 3y ago
    Prior to YAML 1.2, unquoted numeric values containing : were interpreted as base 60, a common trip-up for Docker Compose port mappings. The intent was to make it easier to write times, i.e., 2:00 == 120.
analog31 3y ago
Just to add one more feature request... ;-) Comments are preserved when you read a file, change some of its contents, and write it back out again.
- hnlmorg 3y ago
  I have zero issues if parsers choose to do this but I wouldn’t argue that it shouldn’t be a required part of the specification. If comments need to be preserved then they’re part of the schema and should be a (for example) string field rather than comment.
  - eviks 3y ago
    What's the connection? They can't be a string field because semantically they're tied to another field they're commenting, and they need to be preserved because that info is valuable Why do you require conversion in this use case?
ilyt 3y ago
>I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. You're 90% way there to YAML. And YAML 1.2 cleaned up most of the annoying YAML edgecases too
atombender 3y ago
I like Google's Jsonnet [1], which has all of this except for 4. Jsonnet is quite mature, with fairly wide language adoption, and has the benefit of supporting expressions, including conditionals, arithmetic, as well as being able to define reusable blocks inside function definitions or external files. It's not suitable as a serialization format, but great for config. It's popular in some circles, but I'm sad that it has not reached wider adoption. [1] https://jsonnet.org/ https://jsonnet.org/
- jrockway 3y ago
  Yeah, I like jsonnet a lot for config files.
solarkraft 3y ago
I have a wish I think is superior to trailing commas: Optional commas, like semicolons are optional in JS. Human-readable objects and arrays, like JS instructions, are nearly always already newline-separated.
himujjal 3y ago
Hi. I am the author of EKON. I realized YAML was doing too many things. EKON was meant to be an extension of JSON5. Although right now I realise its also doing too many stuffs under the hood. I should rewrite the project again. But be as simple as possible. That was my first C project ever during my University. :P

4ad 3y ago

Among types and other useful properties, CUE supports everything you asked for. We're even considering adding a "data-only" mode to CUE which would be exactly what you asked for. https://cuelang.org https://cuelang.org

conaclos 3y ago
Is there any concise representation of the language spec? Similar to the spec of JSON [1]. [1] https://www.json.org/json-en.html https://www.json.org/json-en.html
- 4ad 3y ago
  No, we do have a spec[1], but it cannot be as concise as the JSON link posted because the JSON link is mostly only about syntax, and our spec discusses both syntax and semantics. And of course, we are a much richer language than JSON, with many more features and computational behavior. That being said, it would be nice to use railroad diagrams to describe syntax in our spec. [1] https://cuelang.org/docs/references/spec https://cuelang.org/docs/references/spec

codeflo 3y ago

JSON as a computer-generated serialization format doesn't need any of those features. But for human-written configuration files, at the very least trailing commas and comments are basically a necessity. The question then is which features to pick beyond that (in my humble opinion, none), and how such a new standard would gain traction. JSON5, JSON6, JSONC all basically attempt to solve the latter problem by branding, but so far, mostly have failed. It doesn't help that there's an insane amount of bike-shedding going on in this space. The people who have forked JSON5 to create JSON6 for example have created an endless amount of confusion over which standard to use, harming both of them. I think they might want to think really hard whether the inclusion of octal literals was really worth the hostile fork.

chrismorgan 3y ago

I strongly dislike the idea of optional {} on the root object. It’s weird special-casing that adds complexity (code and cognitive) for no adequate reason, destroying the neat contextless recursion of parsing. Remember also that objects aren’t the only valid JSON values; and why should objects be privileged over, say, arrays? You could make [] optional too without introducing actual grammatical ambiguity, other than deciding what to do about the empty string (which “optional {} on the root object” would make valid, unless you special-case it further). But all of these cases require that humans and computers alike look ahead, rather than seeing { and immediately knowing what they’re dealing with.

elondaits 3y ago
Arrays at the root of JSON are dangerous and best avoided: https://stackoverflow.com/questions/3503102/what-are-top-level-json-arrays-and-why-are-they-a-security-risk https://stackoverflow.com/questions/3503102/what-are-top-lev...
- chrismorgan 3y ago
  The matter of literals being interceptable due to using the current value of globals like Array was fixed across the board over a decade ago. You don’t need to worry about it in the slightest. (Exploits also depended on a form of cross-site request forgery that (a) has been well-understood and avoided for fifteen years now (and with a perfect solution available for five years via the SameSite cookie attribute), so if you’re affected you very probably messed up in other exploitable ways too, and (b) is often even protected by default now: Chromium switched the default to SameSite=Lax in early 2020, so the sensitive cookie would need to be explicitly set with SameSite=None in order to be vulnerable at all. Safari and Firefox haven’t yet shipped this behaviour, though they all agree they want to, since it does break some older sites.)
- tadfisher 3y ago
  In the decade (or more?) since that was a problem, ES added JSON.stringify(). Nobody runs eval() to parse JSON anymore, and moreover, the root cause of the exploit (CSRF) has been addressed with CORS and sane default browser policy.

kayodelycaon 3y ago

Let me introduce you to our lord and savior: YAML. ;)

_ZeD_ 3y ago
Yaml is plain unreadable for me tho
hyperhopper 3y ago
Ah yes, the language where a string can magically become a boolean and cause an error. And you can never be sure what is legal because of so many changes in parsing legality between versions. Yaml is one of the worst config languages.
- FireInsight 3y ago
  YAML is great except for everything wrong with it, YAML is the worst except for all the others, etc., etc.
- rgovostes 3y ago
  Prior to YAML 1.2, unquoted numeric values containing : were interpreted as base 60, a common trip-up for Docker Compose port mappings. The intent was to make it easier to write times, i.e., 2:00 == 120.

analog31 3y ago

Just to add one more feature request... ;-) Comments are preserved when you read a file, change some of its contents, and write it back out again.

hnlmorg 3y ago
I have zero issues if parsers choose to do this but I wouldn’t argue that it shouldn’t be a required part of the specification. If comments need to be preserved then they’re part of the schema and should be a (for example) string field rather than comment.
- eviks 3y ago
  What's the connection? They can't be a string field because semantically they're tied to another field they're commenting, and they need to be preserved because that info is valuable Why do you require conversion in this use case?

ilyt 3y ago

>I pretty like the idea of a superset of JSON that supports (1) comments, (2) trailing commas, (3) unquoted properties, (4) optional {} for the root object, (5) multi-line strings, (6) number separator. You're 90% way there to YAML. And YAML 1.2 cleaned up most of the annoying YAML edgecases too

atombender 3y ago

I like Google's Jsonnet [1], which has all of this except for 4. Jsonnet is quite mature, with fairly wide language adoption, and has the benefit of supporting expressions, including conditionals, arithmetic, as well as being able to define reusable blocks inside function definitions or external files. It's not suitable as a serialization format, but great for config. It's popular in some circles, but I'm sad that it has not reached wider adoption. [1] https://jsonnet.org/ https://jsonnet.org/

jrockway 3y ago
Yeah, I like jsonnet a lot for config files.

solarkraft 3y ago

I have a wish I think is superior to trailing commas: Optional commas, like semicolons are optional in JS. Human-readable objects and arrays, like JS instructions, are nearly always already newline-separated.

himujjal 3y ago

Hi. I am the author of EKON. I realized YAML was doing too many things. EKON was meant to be an extension of JSON5. Although right now I realise its also doing too many stuffs under the hood. I should rewrite the project again. But be as simple as possible. That was my first C project ever during my University. :P