Can part of the renaissance be switching to a JSON format? Please?
That being said, I don't see what's "wrong" with XML in this context.
I know a lot of HN folks will say but you can just construct perfectly valid XML with library such-and-such or API this-and-that and, yes, I'm sure they're all absolutely, positively 100% correct. But in my real-world experience, Reece and Simmons seem to be correct in practice. Given that Simmons wrote NNW, worked at the now-defunct server-side RSS company NewsGator, and is now writing a new RSS (and JSON Feed) reader, I'm inclined to believe that when he says JSON Feed "reflects the lessons learned from our years of work reading and publishing feeds," he means it.
Back before I started using the db backend I was parsing the feed with an auto-generated (from the schema) "rss reader" in python then merging the items into a master rss feed sorted by channels. That worked for a while until I got motivated and made it searchable/modifiable but couldn't find a simple database that I could just dump xml into.
Anyhoo, my point is it's easy to work with rss in either native xml or json with some simple tools that do most of the work for you. Would be super easy to bang together a converter that goes both ways if someone was motivated enough.
Actually... now that I think about it, changing generateDS to use a dict to store xml attributes could easily go back and forth with all the error checking one would desire -- might have to hack that together.
The entire JSON spec is only about 3 pages long. (I don't know exactly how long because ECMA's webpage is down today!) I'm pretty confident that any popular JSON parser I use will abort correctly on bad JSON. There's no expansion or entities or escaping, so the parser is a pretty boring 1-to-1 translation. Give it a 1KB JSON file, and I'm going to get back a data structure that takes roughly 1KB.
XML is incredibly complicated. My operating system's XML parser has had XXE-related security bugs in the recent past -- that's OWASP bug#4, and there's a Wikipedia article about it. There's other possible attacks, like the "billion laughs attack". I'm very nervous about running an XML parser on untrusted content.
And that follows for most XML stuff. If you are getting most bloggable with your tech stack, yes, there are certainly risks to XML (also to YAML, also to JSON--and there are definitely JSON parsers that have had some capital-I Issues out there, and a good number of the popular ones also parse not-JSON too). That said, if you're using anything remotely mainstream you can feel reasonably secure against the sorts of attacks you are likely to see because, TBH, your RSS reader is just not that valuable a target. (Or, in my case--the podcast service I'm writing.)
Non web-dev guy here, but browsers have excellent XML parses out there that can turn XML into a document object with a fully fledged query language. Why does it need to be a JS object?
{
"head" : [...],
"body" : [ { "name" : "H1", "text" : "Hello JSON" },
... ]
}