In all fairness, JSON itself continues to be as simple a format as it ever was. Having schemas is an important adjuct because it frees devs up from constantly translating specs into ad-hoc validation routines that all too often miss something or make mistakes. Validation up front saves a tremendous amount of pain dealing with a key error deep in a call stack when the moment a config file was read its omissions or mistakes could have been identified.
Moreover, and on a related note, in many ways, JSON is great as an exchange format, but stifling as a config language. There is a lot if room between JSON and XML to work with.
> In all fairness, JSON itself continues to be as simple a format as it ever was. Having schemas is an important adjuct because it frees devs up from constantly translating specs into ad-hoc validation routines that all too often miss something or make mistakes. Validation up front saves a tremendous amount of pain dealing with a key error deep in a call stack when the moment a config file was read its omissions or mistakes could have been identified.
I agree. JSON is overall better than XML for most things. It's simple and universal. This simplicity translates to the new incarnations of some good ideas that people were trying to implement on top of XML, like schemas. They are not mandatory, but useful in certain domains. Simpler format means that these things can also become simpler. So eventually we may do them right. It's a process of evolution.
> Moreover, and on a related note, in many ways, JSON is great as an exchange format, but stifling as a config language. There is a lot if room between JSON and XML to work with.
Also agree. There is also a tiny bit of room below JSON and above unstructured text that can fit a universal syntax on top of which other formats can be built, including ones for configuration. A modular one. Where you can have different formats that share the same underlying syntactical structure and as much idioms within that as reasonable.
And here comes the pitch: this is what I'm trying to introduce. A simple universal syntax. It is still somewhat undercooked (less the syntax which is minimal and stable but more its description and formats on top of it), but might be interesting for certain people. The thing is called TAO and it has a website here: https://www.tree-annotation.org/
I hope somebody will find this inspiring at least.
`raw` is more of a type annotation than operator. You can also impose an implicit interpretation of (some of) your data as raw, without a type annotation.
One of the best representations of the 'simpleness' is the way you can draw it in a graphical loop diagram as they do on the json.org site.
When you can make your 'format' in to a not-too-big diagram like that it makes it far easier for anyone interested to 'get it' and encompass the whole thing in their mind to work with.
SQLite is the place that (to my knowledge) was the first to do these "railroad diagrams". Here are all of theirs (though they're also available inside the documentation): https://sqlite.org/syntaxdiagrams.html
Definitely not the first, I see that the first release of SQLite was 2000, and I found these railroad diagrams in old Pascal programming books of my father.
Moreover, and on a related note, in many ways, JSON is great as an exchange format, but stifling as a config language. There is a lot if room between JSON and XML to work with.