[wp-hackers] JSON Syndication
elharo at metalab.unc.edu
Wed Feb 21 17:22:56 GMT 2007
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
> 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
Elliotte Rusty Harold elharo at metalab.unc.edu
Java I/O 2nd Edition Just Published!
More information about the wp-hackers