[wp-hackers] JSON Syndication

[Elliotte Harold]

Matt Patenaude wrote:
> I'm not trying to knock XML as a language. XML is very powerful, and I 
> believe that there are many places (particularly in rich documents) 
> where its uses are plentiful. However, I don't think syndication is one 
> of them.

You're wrong. It is one of them. In fact, syndication is exactly the 
sort of application that XML was designed for. It fits that particular 
problem extremely well.

> And what exactly are the needs of full text feeds? I think that matter 
> is up to interpretation, but the way I see it, the entire purpose of 
> online syndication is to distribute a snippet of a larger work in a 
> format that piques the reader's interest, and encourages them to visit 
> the original source to read more.

That's one purpose. It's hardly the only one. Many people prefer reading 
their entire feeds in the feed reader rather than a browser. The market 
has already determined that they want this. The original RSS tried to 
limit itself to what yo;re doing and the audience quickly hacked round 
it because they wanted full text feeds with embedded markup. Your 
proposal. like the original RSS, only solves part of the problem.

> I do not see syndication having the 
> need to convey all of the semantic markup of the document being 
> syndicated. When I read an Atom feed, I honestly don't really care where 
> the author put emphasis. If I want that much info, I'll click the link 
> and read the whole article.

That's fine for you. You don't have to use it. However many authors and 
readers do want this. Your format will not succeed without providing it.


> The format that's doing the syndication is only a container-- RSS is a 
> container, Atom is a container, and this JSON feed format would also be 
> a container. 

RSS is a broken container. Your format is a broken container.

> What would go in the content section could be anything you 
> want, just like Atom. I would probably add a type property to each 
> entry, so that you could specify if the content was text/html, 
> text/plain, or even something a little fancier.

You're going to reinvent double escaped markup, just like RSS did. This 
has already been shown to be a major flaw in RSS and it will be no less 
of one in JSON. Atom does not have this problem. (Well, it shouldn't. 
Some people and plug-ins persist in sending double escaped markup in 
Atom too, but at least it's not required there.)

Those who forget history are doomed to repeat it, I guess.

> Find me an Atom feed 
> that can't be represented by JSON... bet it won't be easy. There's no 
> saying a JSON feed couldn't handle embedded markup (in fact, I had 
> always intended it to).

The question is not, "Can it do it?" The question is it, "Can it do it 
well enough?" More properly, ""Can it do it better or even equally to 
Atom?" The answer to that question is no, it can't.


> Of course, syndication is no use if it's ridiculously hard to implement. 
> I'm not saying that XML is all that bad, but JSON is much simpler. Since 
> JSON relates directly to programming data structures, it's easier to 
> handle and deliver to the people who want to read it.

Syndication isn't about programming data structures. It's about 
publishing document structures. Stop thinking like a programmer and 
start thinking like an author.

Even if it were true that using XML made life harder for the programmer 
(and it doesn't) XML would still be the right answer because it makes 
life easier for the publisher and the reader. The programmers in this 
space are working to satisfy the needs of the authors and the readers, 
not the other way around.

>> The syndication format I see there is much simpler than what people 
>> are sending today with Atom.

True, because people are sending more complex data than your format can 
support.

> A JSON feed shouldn't contain any JavaScript code whatsoever. In fact, I 
> think the callback feature of JSON should not be implemented by scripts 
> generating JSON feeds. Further, it will be encouraged (in big bold 
> letters ;)) that people using the feeds use a JSON interpreter, rather 
> than just eval()'ing it. That eliminates pretty much every problem.

And it's encouraged that programmers always use a good garbage 
collection library and check the results of each malloc before using it. 
That's why we really don't have any problems with buffer overflows any 
more. :-)

-- 
Elliotte Rusty Harold  elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/