Hacker News Reader

Comment by exabrial | Hacker News Reader

> Maybe JSON-based, definitely not XML-based

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.

View on HN

I have worked with XML since it was a wee laddie. I generally prefer using JSON, but all my SDKs emit BOTH XML and JSON (and, occasionally, CSV).

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.

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

https://www.w3.org/XML/Schema

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.

JSON is a really poor format for anything but simple data.

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.

The biggest issue I have with XML is the ambiguity between attributes and child elements. The distinction makes sense in an abstract perspective, but real-world implementations rarely use them in a consistent manner.

One's a dictionary (unordered, simple unique keys), and one's a list (ordered, arbitrary contents, no uniqueness constraints). Schemas may enforce more, but those are the intrinsic qualities.

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.

Is it more logical to have a point tag which has the attributes x and y or have x and y as their own tags and values? Its not clear to me which makes more sense and it seems the spec writes using xml didn't know either.

since x and y are simple names, have simple values, and are unique pairs that apply only once to a point: attributes.

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.

Obviously, if you just reimplement SVG in JSON it's not going to get better, there would be far more to it. And I'm a big fan of strong schemas, it's the best part of XML.

While JSON is far from perfect it is a lingua franca; humans and computers all over the world are very familiar with it. I think this is one of reasons for the growing popularity of the glTF format for 3D models, which also has a binary variant.

Reply on news.ycombinator.com