It doesn't appear there's any schema for this, which I see as a mistake. The validator he linked to accepts any well-formed JSON at all; it has no idea what valid RSS JSON should look like.
I would have done RSS based on http://n2.talis.com/wiki/RDF_JSON_Specification. But then I'm one of those who doesn't understand why RSS moved away from its RDF foundations in the first place.
Nice! XML is overrated, but the definition of RSS is really that it is in XML format. Perhaps it shouldn't be called RSS? Someone should come up with a JSON Schema ( http://groups.google.com/group/json-schema/web/json-schema-i... ) for JSON "RSS" feeds.
XML isn't overrated, but it is often misunderstood and misused.
Know of any other data formats that allow schemas, validation, and transformation/styling of their content to other formats in a mature implementation independent manner?
If you're just moving bits around, use whatever.
If you're trying to create data interchange standards, XML is a pretty good choice.
* Few who were coming up with a format/DTD/schema understood the differentiation between placing value data in attribute values vs. element values.
* Element values would sometimes contain whitespace prefix and suffix due to formatting which caused problems with those values in the beginning.
* The optional XML declaration attribute didn't even fit in with the rest of the spirit of the format.
* The wealth of greater-than, less-than, slashes and quotes in the data was unnecessary, and converting from text to compressed format and back barely ever took off.
* The format allowed having one element partially within the scope of another <like><this></like></this> unlike bracket scope notation that would never have had such ambiguitity.
I could go on and on.
Transformation? Michael Kay may have been the man with the bible in the early 2000s, but I think everyone realized by the mid 2000s that XSLT and related XML transformations were a huge seemingly bottomless pit of wasted effort. What is needed was code, and people keep trying to make XSLT handle logic. Think of what those same people could have written in the same time using Java, Ruby, Python, PhP, Javascript. It is mind-boggling the amount of waste that XML and related formats have caused.
Moving bits around? Bits are moving around no matter what format you use. Why not use something that saves typing, and doesn't waste everyone's time?
All that said. XML is out there. I still do SOAP, WSDL, etc. I still mess with SAX and DOM in Java. I write XML services in Ruby and consume them. It is inescapable.
JSON doesn't yet cover all of the bases, but at least it is on a better track. Once people really think about the problems with XML- only then can we really evolve in the way we write and use unformatted human-readable data documents.
While I agree that it is frustrating to worry about offering things in different formats, JSON is not terrible, and it is much more compact while still being human readable. It is only natural that something easier to read and type than XML would suffer a period of overlap with XML, etc.
Nobody manually enters all the tags for XML/HTML/SGML - you ought to be using an editor that supports some combination of tag shortcuts, tag completion, Zen Coding, or some other schema-aware entry method.
I'd go nuts too if I had to enter all the tags by hand, if my left index/ring fingers didn't fall off first.
The point is that XML, like any format, is not perfect. If you get the chance to transition to using JSON or another well-used less flawed format in the future, why not?
Some clarifications:
* XML's End tags/elements are visual noise and cause additional unnecessary data to need to be stored.
* Greater thans, less thans, and slashes are more visual noise and less intuitive and readable than the brackets, commas, and colons in JSON.
* The fact that you can have values as attributes or as element values has caused confusion since the beginning. Attributes allow 1:1, but schemas can describe 1:1 as element values even though the same element could otherwise appear multiple times and be 1:*. Why should you be wasting time having to decide which to use when you are trying to define a format?
Few bust on XML because they think that would be lunacy, since it is so prevalent. If everyone uses it, it must be better right?
I've been playing with the python dict output by http://feedparser.org/, which converts to JSON really nice (once you wrap the time object output). Admittedly schemaless, but it seems to normalize a bunch of different feed formats really well and predictably.
I would have done RSS based on http://n2.talis.com/wiki/RDF_JSON_Specification. But then I'm one of those who doesn't understand why RSS moved away from its RDF foundations in the first place.