XML Schema is the main reason I use XML. I hate Schema. Hates HAAATESSSS NASSSTY SSSSCHEMA..., but it is ironclad. If it is described in Schema, then it is guaranteed (or not; in which case Schema also accounts for that).
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.
If anyone wants REAL pain, then we should go back to BNF: https://en.wikipedia.org/wiki/Backus–Naur_form
I worked with a BNF compiler, and I still wake up screaming.
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. :)
But note "draft."
Compare to: https://www.w3.org/standards/xml/schema
Hasn't stopped tooling from being built around it.
I fail to see any benefit of a rigid, typed, schema'd JSON that XML does not offer more naturally.
JSON schema let's you make that a bit safer.
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.
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
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
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.
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...
That's work for whoever is producing the document, but wonderful for all the consumers.
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.
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.
The flip side is that you will never find a JSON with the structure "{ "zoom": "startZoomMarkup" }5{ "zoom": "endZoomMarkUp" }".
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...
Often what you want is instead to generate an AST, in that case you will run into ambiguosness problems.
XML may be verbose and not readable, but it is an excellent format for describing and storing data.
One alternative for SVG could be an SQL table like datastore, similar to sqlite. I would love yo have the ability to query data, rather than parse through XML. I do understand that transferring such data blobs over networks is an issue.
I agree that use varies widely, but the difference is fairly clear. The existence of nonsense doesn't mean one can't make good decisions.
to use anything else means relying on an arbitrarily-complex custom schema rather than the much-simpler-and-far-more-standard schema of the language itself. similar to how we use datatypes in programming languages rather than just strings everywhere. both work! one is clearly giving up a lot, and gaining little.
No.
Strong schemas are _why_ it's supported across a multitude of platforms. JSON because "it's got JSON, what plants crave" is an absolutely dumb argument. And the see article "parsing JSON is a minefield". I can't think of a way to make the standard worse than re-implementing in JSON.
There are some legit missing features from SVG as other commenters have pointed out. To me, it sounds like the tooling is actually what's lacking. The equivalent of minifying or even the option to render xml to a binary representation is probably what is actually lacking.