
RSS data in JSON format - davewiner
http://scripting.com/stories/2010/10/09/nextStepsInTheFeedhoseProj.html
======
prodigal_erik
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.

------
devmonk
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...](http://groups.google.com/group/json-schema/web/json-schema-
implementations) ) for JSON "RSS" feeds.

~~~
zdw
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.

~~~
devmonk
There are a quite a few problems with XML:

* 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.

~~~
davewiner
The only reason I added JSON is so that people could use it in places that you
can't use XML.

I wish the designers of JavaScript had been less keen on reinventing things.
Yet another format we all have to support. Sigh.

~~~
devmonk
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.

~~~
zdw
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.

~~~
devmonk
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?

------
thwarted
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.

