Blog-debate on XML vs. JSON with @davewiner

If you’re reading my blog, odds are you are familiar with Dave Winer already. Dude invented RSS and as his Twitter bio succinctly puts it, he’s been blogging as long as there’s been blogging.

So I wanted to avail his offer for a blog-debate on XML vs. JSON. Here’s Dave’s premise:

Anyone want to blog-debate about XML vs JSON? I’ve spent years using both, I think I have an objective view of the strengths of each. Imho, they are almost the same thing. XML has attributes and values, and that does make it more complex. Slightly. But you don’t have to use the extra features. Look at OPML for an idea of a simple very JSON-like application of XML.

I grew up on RSS and its kin. One of my favorite projects at Thunderdome was developing an NITF format to syndicate our content across network (with the benefit of hindsight, an RSS 2.0 implementation would probably have been better).

But it’s also undeniable that JSON has proliferated over the last decade. This summer’s introduction of JSON Feed typifies this transition from XML to JSON. I saw it mentioned on Daring Fireball, which is how I heard of it.

Let’s take a minute to separate the baby from the bath water here. The JSON Feed creators identified legitimate shortcomings of “standard” RSS. An example in the WordPress context might be custom post types. RSS out of the box doesn’t have the vocabulary to describe additional types of objects, but that’s precisely why RSS 2.0 namespaces exist. Other examples included the addition of a banner image; again, good idea, but germane to publishing in general and not JSON in particular.

Update 12:16pm: Dave informed me that there is also RSS in JSON, which has appeal for schema term consistency between formats

All this to say, I expect RSS to remain the dominant form for feed-based syndication as we know it today. It’s really good at that!

That said, I am spending most of my time these days touching JSON, not XML.

This is because the trend towards API-driven experience and more specifically RESTful experiences. This technology paradigm was driven by the valley but adopted by publishing industry, notably through the WP API project. In general this trend is driven by more happening on the client that’s specific to a user or context. My understanding is that SOAP protocol can satisfy this need, but when that client dev is likely happening in ES6 already, why bother with a detour through XML land?

That said, JSON Feed format is notably not an API. I mentioned this to Gruber and Dave on Twitter, they agreed it was an interesting idea. I’ve been lightly pondering this space as Alley is looking hard at headless publishing. RSS might remain the standard for broadcast feeds but is there a similar standard for content API? We’ve got the WP API project, Contentful has an API, but it doesn’t seem like there’s a standard here.

What do you think? I’m using Coral Project Talk below, so leave me a comment!

Posted Jun. 21 2017, 12:01 pm by davis