Comment by indymike | Hacker News Reader

Comment by indymike | Hacker News Reader

I've been involved in XML standards making for about seven years, and one of the things I'm most proud of is encouraging the standards body to publish a JSON standard.

XML is extremely flexible, and delivered on being extensible. That is why it has fallen out of favor. XML is pretty unforgiving in terms of what is valid (this is all for good reason) and the extensibility brings with it a lot of complexity. XML is:

- Complex and requires tools with more functionality than, say JSON. Yes other formats do less. That is why formats like JSON are supported completely in most languages and XML and it's dependent standards. For example SOAP is not fully supported by Python.

- Brittle. It is easy to introduce errors in XML that cause most XML parsers to fail. Bad characters, bad or missing escapes, unbalanced tags all introduce points of failure.

- XML is the foundation of even more brittle and complex standards like SOAP and XHTML. Yes, SOAP is really cool. WSDLs when supported are magic. But... when something isn't right, it's very difficult to fix or get working. Meanwhile, a mediocre developer can integrate with a web api that delivers JSON in an hour or two.

While XML can do the job, JSON, YAML and TOML all are a lot smaller in terms of tooling and cognitive overhead, and most importantly, writing a library to handle them is much less daunting than supporting XML and all of it's child standards.

All that said, for more complex data interchange cases, and internal file formats, XML still is hard to beat. So much work is done for you.

Whenever someone mentions SOAP I’m always reminded about this funny article “S Stands For Simple” [0].

———

[0]: http://harmful.cat-v.org/software/xml/soap/simple

It is "Simple" in contrast to things like CORBA and DCOM. Which it accomplishes by not solving the main problem that these distributed object protocols try to solve at all and instead being overly complex RPC protocol with completely unnecessary "object orientation".

On a similar note, the L in LDAP stands for lightweight, which was accomplished by removing advanced authentication features from X.500 DAP and then gradually reimplementing the same functionality with significantly more complex "simple" "framework" that in theory allows usage of any conceivable authentication mechanism, or something like that.

I lived much of that story, and it's only the slightest exaggeration.

I see the main problem of XML in it's model not matching the data model you usually work with. In code you work with arrays or structs/objects that have members. Members can be other structs or arrays or primitive types. Arrays can be composed of structs, arrays or primitive types (sometimes heterogenous, but not very often).

This does not map to DOM at all, in any direction. In XML DOM you have structured nodes intermixed with text, order of nodes is significant (or may not be) and you have attributes. On top you have namespaces.

Indeed, you can restrict to subset of XML and find a mapping that works, guaranteed you will get a very verbose XML that is hard to work with.

I would generally avoid XML, but the alternatives aren't perfect either, which is to say I sympathize to a degree with people who are familiar with XML and dissatisfied with the shortcomings of the alternatives. YAML and TOML are both pretty complex in their own rights--really what I want is JSON with comments and multiline strings for the "human reader/writer" use case. Never the less, I've never been so pained by these deficiencies that it made sense to use XML.

> really what I want is JSON with comments and multiline strings for the "human reader/writer" use case

Sounds like you want json5: https://json5.org/

It also has the "Arrays may have a single trailing comma." feature which is a pain to not have in json.

Oh yeah, I forgot to include the trailing comma in my list of wants. But yes, I probably want something like json5, albeit it would be nice if it had the traction that YAML and company enjoy. One problem with most of these JSON++ dialects is that they tack on a bunch of low-value features like single-quoted strings and unqouted keys that complicate building parsers and facilitate stylistic differences.

> encouraging the standards body to publish a JSON standard.

Were you successful?

Yes.

where can I find it?

hropenstandards.org it used to be called hr-xml.

Reply on news.ycombinator.com