Following Jon Udell's lead, and based on Aggie's support for the function, I've converted my rss2 feed to support content:encoded.

Excellent. I have a question.

I know entity-encoding HTML is permissible according to the mod_content spec. (I made an embarrassing oversight on this before. [1]) Why not use CDATA? It was put in the XML specification for this express purpose, not entity encoding. I understand entity-encoding HTML is common practice. (I have my suspicions to how that may have gotten started, but they're irrelevant.) It seems that CDATA is the smarter route.[2] How many aggregators would choke on the use of CDATA?

[1] http://weblog.infoworld.com/udell/2002/09/09.html#a405
[2] http://www.mplode.com/tima/archives/000094.html

Practically all of them is my guess. As of last April, when Steve was starting to work on RSS for Blogger Pro, he did a test feed with the description in a CDATA section, and at that time it failed in NewzCrawler, Feedreader, and AmphetaDesk (i.e., every RSS reader I had at the time). Aaron Swartz's feed is using CDATA in content:encoded, and although I've been too lazy to formally test it, I suspect that's what keeps killing Aggie for me. It's the Right Thing To Do, but someone needs to do some serious evangelizing before it will be a safe thing to do.

Aggie should be able to handle CDATA sections. Personally I am subscribed to Aaron's feed and JoelOnSoftware and Aggie doesn't have a problem with either of them, though I *do* frequently get timeouts from Aaron's site. If you do find a feed with with CDATA that Aggie is choking on please let me know.

Thanks,
-joe

Serious evengelizing? (sigh.) Yes. What do you think I'm trying to do. ;) Feel free to join in.

Aaron's feed does choke AmphetaDeak right now. As Sam just noted[1] Aaron's feed is not well-formed XML right now. I think that may have more to do with it then CDATA. Joel's feed get parsed just fine.

I'm using modified version of Blagg (an ultral liberal parser) that handles CDATA. Otherwise Blagg has issue with CDATA -- it parses a description, but doesn't lay it out properly becasue the browser doesn't know what to do with CDATA and ignores it all. (It took one line to fix this problem though. The joy of open soure.)

I tested these feeds with my MovableType plugin[2] and underlying liberal parser. It took in both feeds fine. (Its using the XML::Parser::Lite module where I'm running it rather then XML::Parser that AmphetaDesk or RUWF uses.)

Can't speak for the others.

[1] http://radio.weblogs.com/0101679/2002/09/19.html#a831
[2] http://www.mplode.com/tima/archives/000101.html

Straw ( http://www.nongnu.org/straw/ ) uses my ultra-liberal RSS parser, which will parse both description and content:encoded, with or without CDATA.

Right concerning Aaron's feed - AmphetaDesk is not liberal at all... if the XML is borked, then it won't even try to parse it. Last I knew, however, AmphetaDesk did support CDATA sections - I'd be really surprised if it didn't. As a matter of fact, when Aaron was using mod_content, I added support into the templates for it, and complained to him that it *wasn't* using CDATA sections. It was far easier for me to deal with CDATA then unencoded HTML at the time.

Either way, AmphetaDesk can support content:encoded (if it's CDATA'd) with a one second addition in the default template file (default / template / index.shtml) - just look for:

$OUT .= qq{ $item->{description} } if $item->{description};

and add right below it:

$OUT .= qq{ $item->{"content:encoded"} } if $item->{"content:encoded"};

Caveat: I didn't have time to actually try this.

Choking Aggie: just downloaded a fresh copy of RC4, deleted all the feeds, added the Swhack feed, and got "Failure transforming the data into Aggie.html. There is probably an error in the XSL file: object reference not set to an instance of an object."

Ooooh, *that* feed from Aaron. I was talking about http://aaronsw.com/weblog.
I will take a look at it. Thanks!

-joe

Update: It's not a bug with the XML. I will post more info once I have the bug nailed down and a fix in place.

-joe