[hexxiiiz]

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.

[pa7x1]

XML is a document mark-up language, which was repurposed as a data exchange format and configuration format. A mistake in both cases.

JSON is a data exchange format which is sometimes used as a configuration format, also a mistake.

Will we go full circle and start using a configuration language for data exchange or mark-up? TOML APIs?

[djedr]

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

If so, here is a thread on HN for discussion: https://news.ycombinator.com/item?id=23966667

[tgb]

How does your raw operator work with data that contains a closing bracket?

[djedr]

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

A (not necessarily the clearest; this is something I have to work on) description is here: https://www.tree-annotation.org/raw.html

To condense: If it's unbalanced you have to escape it with the grave accent `. Otherwise, if it's balanced, which is mostly the case, no problem.

Unbalanced brackets and consecutive grave accents (or a grave accent followed by a bracket) are the only things you need to escape in raw data.

For more discussion let's go to the other thread, not to hijack this one.

[oneplane]

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.

[koenigdavidmj]

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

[rbonvall]

As far as I know, they were originally introduced by Niklaus Wirth to describe Pascal's syntax. See the last pages in this manual from 1973: https://www.research-collection.ethz.ch/bitstream/handle/20....

[jhrwalter]

They even go back to Algol 68: http://www.softwarepreservation.org/projects/ALGOL/book/Lind...

[heinrich5991]

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.

[1wd]

For example Turbo Pascal included a Language Guide book that documented the entire Object Pascal language with railroad diagrams:

https://archive.org/details/bitsavers_borlandturVersion7.0La...

[hans_castorp]

Oracle had those always (even back when only printed manual were available)