It's unfortunate that XML has fallen so out of favor that well-made, strongly-schemad formats specified in XML, like Atom, are suffering in turn -- although reasons for feeds' demise go well beyond its forms-on-the-wire. This trend frustrates me, but it's undeniable that a lot of web data interchange happens with JSON-based formats nowadays, and the benefits of network effects, familiarity, and tooling support make JSONification worth exploring.<p>But even more frustrating is when a format comes out that's close to being a faithful translation of an established format, but makes small, incompatible changes that push the burden of faithful translation onto content authors, or the makers of third-party libraries.<p>I honestly don't intend to offer harsh targeted critique against the authors -- I assume good faith; more just voicing exasperation. There have been similar attempts over the years -- one from Dave Winer, the creator of RSS 0.92 and RSS 2.0, called RSS.js [1], which stoked some interest at first [2]; others by devs working in isolation without seeming access to a search engine and completely unaware of prior art; some who are just trying something unrelated and accidentally produce something usable [3]; finally, this question pops up from time to time on forums where people with an interest in this subject tend to congregate [4]. Meanwhile, real standards-bodies are off doing stuff that reframes the problem entirely [5] -- which seems out-of-touch at first, but I'd argue provides a better approach than similar-but-not-entirely-compatible riff on something really old.<p>And as a meta, "people who use JSON-based formats", as a loose aggregate, have a serious and latent disagreement about whether data should have a schema or even a formal spec. In the beginning when people first started using JSON instead of XML, it was done in a schemaless way, and making sense of it was strictly best-effort on part of the receiving party. Then a movement appeared to bring schemas to JSON, which went against the original reason for using JSON in the first place, and now we're stuck with the two camps playing in the same sandbox whose views, use-cases, and goals are contradictory. This appears to be a "classic" loose JSON format, not a strictly-schemad JSON format, not even bothering to declare its own mediatype. This invites criticism from the other camp, yet the authors are clearly not playing in that arena. What's the long-term solution here?<p>[1] <a href="http://scripting.com/stories/2012/09/10/rssInJsonForReal.html" rel="nofollow">http://scripting.com/stories/2012/09/10/rssInJsonForReal.htm...</a>
[2] <a href="https://core.trac.wordpress.org/ticket/25639" rel="nofollow">https://core.trac.wordpress.org/ticket/25639</a>
[3] <a href="http://www.giantflyingsaucer.com/blog/?p=3521" rel="nofollow">http://www.giantflyingsaucer.com/blog/?p=3521</a>
[4] <a href="https://groups.google.com/forum/#!topic/restful-json/gkaZl3AtiPk" rel="nofollow">https://groups.google.com/forum/#!topic/restful-json/gkaZl3A...</a>
[5] <a href="https://www.w3.org/TR/activitystreams-core/" rel="nofollow">https://www.w3.org/TR/activitystreams-core/</a>