[dgreensp]

Thumbs down.

He taught an entire course on XML, which he calls a "great meta-example on how to deal with semi-structured data"? And his only defense of XML over JSON is... it's worked ok for some file formats?

The only point in this whole article is that XML is not well-suited for RPCs, though he fails to argue that it's well-suited for anything else.

One argument is that XML is better than JSON for use cases like XHTML, where you heavily mix tags and content. I get the feeling XML wasn't really made for this case, though, it was made for the JSON-like case. Processing XHTML with E4X (the "XML for JavaScript" standard) is painful, and XML libraries in general assume your document basically consists of a tree of tags, maybe with text nodes at the leaves.

I was expecting some argument invoking the power of DTDs and XSLT or whatever else, or the original point of XML that people overlook, and all I got was an extremely weak defense of XML from someone who taught a whole course on it.

[jamesbritt]

"I get the feeling XML wasn't really made for this case, though, it was made for the JSON-like case."

Back in 1997, XML was "SGML for the Web." It was a way to pass around structured, plain-text, human-readable documents that did not require expensive, buggy, incomplete parsers.

It then got misapplied as an RPC transport encoding, and tools vendors were more than happy to start pushing specs, such as W3C Schemas, that demanded the use of tools.

It started out to be simple, but, as things happen, got hijacked. But the fault is with the misapplication, not XML itself.

[jasonwatkinspdx]

If you read the annotated xml spec, it really is quality work. I don't necessarily agree with every design decision, but I think a lot of people look at the complexity of xml applications and falsely blame xml itself.

Sadly there were some sensible early formats that were left behind. XML-RPC's serialization is a bit verbose but otherwise is quite similar to JSON. Somehow that got turned into SOAP and then eventually the WS- tar pit of complexity.

Likewise XML as a configuration file language can be quite elegant, almost like a literate coding version of common .ini or .conf files. But instead of this simple flat document littered with variables, xml config files in the wild end up with deeply nested structure that contributes dubious value and makes the files far less human friendly.

XML itself, with the possible exception of namespaces and a few other features, is quite simple. I totally agree it's the applications that have gotten out of hand, particularly in areas where XML is used as structured data exchange rather than document markup.

[jimbokun]

I guess the reason why this happened was because we didn't have JSON then, so XML looked like the best available option to many people at the time (except for those few who knew about s-expressions).

Now that we have JSON, there is no longer any excuse.

[jaaron]

If you believe his best point is that XML is not well-suited for RPCs then you've missed the point.

XML is good for exactly what it stands for: an extensible markup language. It's good for dealing with semi-structured data, especially when you have to deal with data from multiple domains.

Have you ever used SGML (other than HTML)? If so, then you'd likely agree that XML is a superior standard. But I'm guessing that you have not, because for some reason you believe that XML was created for data serialization.

DTDs and XSLT _are_ useful aspects of XML and I doubt the author in unaware of them. Rather the author assumed too much of the readers in understanding the history of XML and the nature of semi-structured data.

[fauigerzigerk]

I don't agree at all. Mixed content was once the primary use case for XML. XML and SGML before it was made for marking up documents and documents contain mixed content. They're not databases and they're not message formats containing structured data.

[flogic]

The only good point for XML is there are existing tools that do things via XML. There are tools that generate ATOM and RSS for you. And there are tools that consume ATOM and RSS. So if XML is already a well defined and followed standard for what you want do, use XML. In all other situations use something else.

[fauigerzigerk]

<p class="content">Then help me translate this into <span class="highlight">JSON</span> please</p>

How about that way:

{tag: "p", class: "content", text: ["Then help me translate this into ", {tag: "span", class: "highlight", text: "JSON"}, " please"]}

And that's just a small example where you can see all the start and end tags on one screen. Now change the example to insert a hyperlink, say, around the word "help". How easy is it to change?

[flogic]

Who said anything about JSON? XML is just shit. It requires documents be well formed which sucks when you want a secretary to deal with the documents. It's just a poor combination strict and loose.

[fauigerzigerk]

The difference between a format that adheres to some deterministically parsable syntax and one that doesn't is not something that I would characterise as "shit" or "not shit".

[jimbokun]

"One argument is that XML is better than JSON for use cases like XHTML, where you heavily mix tags and content."

Yes, this is true. The point of using XML is when you have data where you know the structure of some parts, but not others. This is true of most things that begin life as prose, and then have some structure added to them later. It is a point between "bag of words" information retrieval, and SQL queries, that requires a different approach.

"I get the feeling XML wasn't really made for this case, though, it was made for the JSON-like case."

No, this is false. XML is awful for the JSON like case. What would make you think that XML was created for it?