> JSON Schema is a non-starter. No one ever seems to use it, and I don't think it ever made it out of committee. It pretty much goes against why JSON is popular.

My company heavily uses JSON schema.

The OpenAPI project uses JSON Schemas, and AWS also allows for their usage in places.

And finally, there are a couple good projects that automatically generate JSON Schemas from Typescript definitions, which is my preferred way to go. :)

This is nicely done: https://json-schema.org/specification.html

But note "draft."

Compare to: https://www.w3.org/standards/xml/schema

It's been "draft" for years.

Hasn't stopped tooling from being built around it.

Whenever I encounter JSON schema, It makes me aware that the important difference between JSON and XML is not the syntax (my IDE handles that fine), nor the features. But the difference in rigidity. JSON when agility is needed. XML when rigidity is needed.

I fail to see any benefit of a rigid, typed, schema'd JSON that XML does not offer more naturally.

Lots of APIs pop out JSON.

JSON schema let's you make that a bit safer.

My point is that if they need this "safer", why not pop out XML instead.

The largest benefit of JSON is that is not XML. That it doesn't get bogged down in schema's, strong typing, interfaces, contracts and so on. You loose all that by turning JSON into XML-written-in-a-different-syntax.

BNF is just a notation for describing a formal language. Although there are many slight variations of BNF in use, BNF is generally used to describe very precisely the exact syntactically legal sentences (that is, sequences symbols) that belong to a formal language.

Some languages are simple, for example the language that is any sequence of one or more 'A'.

A, AA, AAA, AAAA and so forth are all valid sentences in this language. This is a particularly simple language, but it could be described in BNF:

    <S> ::= A | <S> A

This language could also be specified as { A^n | n >= 1 } using a set notation or as a regular expression like A+

A slightly more complex language is the language of all sentences made up of a sequence of A and B in any order followed by a sequence of C exactly twice as long as the A's and B's together:

    <S> ::= <X>CC | <X><S>CC
    <X> ::= A | B

Legal sentences look like: ACC, AACCCC, ABCCCC, BABCCCCCC, etc. Such a language can't be described by classical regular expressions, but can be described by the context-free grammar expressed in BNF above.

There are alternatives and generalizations of BNF notations. Wirth used railroad diagrams to describe the syntax of PASCAL in the Pascal Report describing his language. This are more visual, but not more powerful.

BNF might be a pain, but there is generally no simple way to express complex syntax requirements for programming languages. BNF isn't used to solve the same problem being addressed by XML or JSON which are methods to encode data.

BNF is an archetype of declarative language.

But I used to work on an X.400 system, and we would have to map out data structures in BNF, pass it through a BNF/X.409 compiler that always hashed things up (often our bad, but that was back in the "big iron" days, when we would have to arm-wrestle for compiler passes), then, once we fixed the X.409, we'd need to pass it into a X.409/C compiler.

And fix it again...

I think, when developers don't like working in XML, it's because the tool forces them to do the job properly.

That's work for whoever is producing the document, but wonderful for all the consumers.

> because the tool forces them to do the job properly

I'd argue the same restrictions on "setting handwave to maximum" and "XHTML doc has one missing brace, no web page at all now" are two extremes that have their parallels in the 'dynamic vs static typing', 'immutable pure vs mutable impure functions', 'XML vs JSON (oh wait!)', and 'web app vs native program' arguments that we HN readers love to debate.

The trick is finding the happy medium between both extremes. Training some 'slackers' to "do the job properly" and convincing some 'purists' to be more pragmatic to the limitations of the world around them.

After all, we need something to occupy us during this Eternal September.

It's a trap. You only need to find the happy medium if you accept the constraints that generate the trade-off in the first place.

And in at least three of the four antagonisms you list, it comes down to the DX of the tooling. Static typing isn't so much of a pain if your type errors are helpful and descriptive. The missing brace in the XHTML doc is easily found when using proper and easy to use XML linters. And I don't see why writing native apps shouldn't be as simple as writing web apps. At least there are attempts that seem to get some mileage out of the idea (e.g. Revery, Flutter).

The trick is to make the toolset more approachable.

> I think, when developers don't like working in XML, it's because the tool forces them to do the job properly.

The flip side is that you will never find a JSON with the structure "{ "zoom": "startZoomMarkup" }5{ "zoom": "endZoomMarkUp" }".

> If anyone wants REAL pain, then we should go back to BNF...

Ironically, if one wants to implement a SVG reader they have to use the BNFs provided in the spec (for paths and whatnot).

Though the SVG 1.1 DTD is pretty nice to work with, I've built a SVG DOMish generator for both c++ and python (which takes forever to compile) so one, err...me, doesn't have to deal with all the underlying XML craziness. One of these days I'll get around to finishing the path parser, color parser, transform parser, &etc...

Hedge grammars have really nice features, which can be parsed by a class of pushdown automata. However, my experience is that not many people understood and valued those features in the XML ecosystem (see SVG but also Xpath). Would be nice to see actually a schema first language that has a good binary and human readable representation. IMHO we can do better than zipped JSON even if is hard.

what's wrong with BNF? as a language descriptor it's simple and concise, isn't it?

Context free grammars are insidious to use in general. The natural way to use them is to either generate all/random legal strings or check if a string matches the grammar.

Often what you want is instead to generate an AST, in that case you will run into ambiguosness problems.

It's a great data description language, but was NOT fun to work with, semantically.