Live data from Hacker News

Don't Invent XML Languages (2006)

tbray.org

11–20 of 99 posts

Re: Don't Invent XML Languages (2006)

#11

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and n…

I’m sure it’s down to use case and circumstances but I frequently find it useful to be able to read and edit text based data formats (JSON/YAML/TOML). If you are concerned about data size you can easily use on-the-fly compression at little cost nowadays.

Re: Don't Invent XML Languages (2006)

#12

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and n…

In my experience people read the JSON output of things more often than anything else in both development and in maintenance. You can certainly make a point about that being stupid, and it certainly also is stupid. It just seems to be what happens when you have a gazillion APIs and even more business processes and a lot of people who should know what they are doing, who don’t.

I recently had the joy of reverse engineering a terrible piece of JavaScript which created a vast and ridiculously complicated JSON delivery for one of our most important frontends. It was so full of any assumptions that the original author had several functions which were still doing various things with “unknown” because the data which had once been there wasn’t. Anyway, since I had to reverse engineer it from terrible code and no documentation I figured I’d just talk with the people who worked the data inputs and outputs and maybe learn something about the process from their business processes. Turns out they couldn’t help, what was even worse was how the frontend partner we were delivering the JSON to couldn’t even explain why they needed it the way it arrived. Those were some “fun” sessions trying to Sherlock Holmes out of the mess. This was a bad story, but it’s just one out of a thousand such stories in enterprise and non-tech IT.

I think the reason JSON “won” over XML was the ”same” human reason. I’ve seen a lot of XML, but I don’t think I’ve ever seen some that didn’t break its own standards. Like you’d get all XML with data between >… because duck you, or whatever else. Often they wouldn’t bother supplying you with schemas, or if they did, their auto-generated schemas wouldn’t have been updated in five years because apparently someone forgot that. Then once you “progress” beyond the technical funzies you’ll still have to deal with using the XML to find out what the hell is going on, and since it’s much harder to read (not entirely sure why) you’ll have to first convert it into JSON anyway, before whatever business process person has to read it.

Re: Don't Invent XML Languages (2006)

#13
post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

I could be wrong, but I recall that during the early AJAX days, there was a bit of a XML v JSON war that ended up with JSON winning. Some stated cases for JSON was that it was less verbose and therefore cheaper to send over the wire, among other stated advantages. I'm sure there were plenty of other sources of fatigue like XHTML Schemas etc...

We’d all been burned on enterprisey balls of mud like XMLRPC and then SOAP. When JSON-over-HTTP came along, it was a breath of fresh air. Look, it’s readable! It’s easy to parse! It’s trivial to generate! It only had like 5% of XML’s features, but that was the point. Mere humans could read it and there was no temptation to stick something in an attribute instead of a value.

Seriously, it was revelatory.

Edit: Also, lots of common computer interactions — I’d go so far as to say most of them — are only passing around a few values in a simple data structure. JSON’s good for that. I wouldn’t want to necessarily use JSON to represent an office document, but that’s not what I want to use it for. “Hey API server, give me information about song 1234.” “OK, that’s ’Hotel California’ by The Eagles.” You can definitely describe both question and answer with XML, complete with schemas and all, but does that get you anything over {“name”:”Hotel California”,…}? Not really.

Consider how much you can accomplish with POSIX, and it doesn’t even have named arguments. There are times when XML’s complexity is a benefit (I guess; I’ve never seen one but I don’t doubt they exist). Most of the time, it’s just overhead for the sake of overhead.

Re: Don't Invent XML Languages (2006)

#14
post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

I had nightmare debugging sessions with Xml and xslt. Xml is big and ugly. Json was so much lighter and easier and so it won.

Re: Don't Invent XML Languages (2006)

#15
post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

I could be wrong, but I recall that during the early AJAX days, there was a bit of a XML v JSON war that ended up with JSON winning. Some stated cases for JSON was that it was less verbose and therefore cheaper to send over the wire, among other stated advantages. I'm sure there were plenty of other sources of fatigue like XHTML Schemas etc...

I think the reason that JSON won was that at least on the client-side, it was much easier to turn the response data into a Javascript object to interact with then XML.

Re: Don't Invent XML Languages (2006)

#16

2006, well into the era of XML being the trendy fad that every piece of Serious Business software was supposed to use. Now 18 years later, JSON seems to have displaced it. Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and n…

> Personally, I've never found text-based formats to be a good choice for data that humans will rarely need to read or write; I much prefer simple and efficient binary formats, which can be just as extensible without the additional inefficiency and needlessly-introduced-failures of string handling.

Many modern serialisation / deserialisation libraries (like Rust's serde) let you serialise your data structures to a variety of formats, including both JSON and various binary formats of your choice.

But it should also be relatively easy to take any binary format, and define an alternate text based format for it that allows one-to-one conversion in both directions. A bit like assembly vs binary machine language.

Re: Don't Invent XML Languages (2006)

#17

I don't even know why we have any *ML. Everything they can do can be done with Lisp-syntax better.

XML is a document markup language. As in, articles and books n stuff. How in hell is that comparable to anything "Lisp-syntax"?

Because lisp syntax (s expressions) are a cleaner and terser superset of all markup languages, and even of JSON-like representations.

IOW, if you take Lisp expressions, add cosmetic syntactical changes like angle brackets and closing tags, then remove about 90% of functionality and cripple what's left, you'll have XML.

Cripple it further and you'll have JSON.

Re: Don't Invent XML Languages (2006)

#18

Another standardized XML language that the article doesn't mention is RDF: https://en.wikipedia.org/wiki/Resource_Description_Framework

RDF is listed on the linked page ("known XML languages"):

https://xml.coverpages.org/xmlApplications.html

SVG and MathML are also listed there, both of which seemed to be used a fair bit.

Re: Don't Invent XML Languages (2006)

#19
post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

JSON is basically a subset of JavaScript. Parsing XML sucks, everyone rolled their own RSS and it was basically a nightmare having to deal with invalid XML. JSON has always been really strict and simple. If JavaScript in a browser couldn't parse it it just didn't work. libxml was also a nightmare, XSLT pages looked terrible and honestly there where just a lot of bad XML ideas out there despite gems like SVG. SOAP was horrible, and still is for people having to interface with a SOAP API like Netsuite.

But what was really the end of XML was the end of XHMTL and the HTML5 working group that said they weren't going to do XML HTML and it was funded by Google's large sums of money and involved talented people work at a hot new browser called Firefox and the web dev community went their way and everyone followed.

Re: Don't Invent XML Languages (2006)

#20
post #9

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

I don't know exactly when, but I think it had a lot to do with the fact that in 2004, Python, Ruby, and yes JavaScript were all fairly niche.

(This might be hard to believe for some, but it's true. GMail had just come out, and it was one of the first web APPS in JavaScript, certainly the first really good one. Paul Graham wrote "the Python paradox" https://paulgraham.com/pypar.html , and Ruby on Rails didn't exist yet.)

JSON maps well to core data structures of Python, Ruby, and (obviously) JavaScript, but XML doesn't.

XML seemed to be associated with Java. There was a lot more ceremony around the APIs. You didn't just manipulate data; you had to create classes and call methods.

So basically neither JSON nor XML are really convenient in Java. But JSON is very convenient in the dynamic languages. You don't need extra abstractions / layers / code generators -- it's just "there".

Post reply on HN