I've been tinkering again with my RSS feeds. First, I found and fixed the problem that was causing the alternate "long-descriptions" feed to sometimes break. The problem was that, when an item is tagged with a category, the feed got processed twice -- and the second time through, there was no <content:encoded> item to latch onto and turn into the <description>. The fix, for now, is to not postprocess category feeds. In general, I'm rethinking this whole business of rendering categories as completely separate HTML subtrees and RSS feeds. It feels too heavyweight. The primary feed, after all, includes things like
Another experimental change: I've tweaked the transformation applied to the default feed so that it truncates the <xhtml:body> in the same way that the <description> is truncated. For now, only the first element is included. Here's the XSLT template, if you're curious:
<xsl:template match="//xhtml:body">
<body xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xsl:copy-of select="./*[position()=1]" />
<p>
[Full story:
<a>
<xsl:attribute name="href">
<xsl:value-of select="ancestor::item/link"/>
</xsl:attribute>
<xsl:value-of select="ancestor::item/title"/>
</a>
]
</p>
</body>
</xsl:template>
I'm doing this for a couple of reasons. First, because I've realized that the newer readers, like SharpReader, pick up the <xhtml:body> by default. For the same reason that I truncate <description> for older readers -- namely, to ensure the scannability of my feed amidst a bunch of other feeds -- it seems I should also now truncate <xhtml:body>. Those who really do prefer to take the entire contents of each item in the feed can still use the alternate feed. Personally, I'm still annoyed by feeds that dump full items into my aggregator, and I still consider item truncation to be the polite way to present your feed.
Still, I'm not certain I'll stick with this policy. One of the reasons I created the full <xhtml:body>, after all, was that I wanted to encourage aggregators to offer the kinds of advanced XPath searching I've been exploring lately. Truncating the <xhtml:body> conflicts with that desire. With respect to polite presentation, an advanced aggregator that receives a full <xhtml:body> can choose to truncate -- even on a per-feed basis -- at the user's discretion, without being constrained by the feed provider's policy.
Clearly other issues are in play as well. Since InfoWorld.com is an ad-supported operation, the fact is that any kind of full-content feed can be used to disintermediate the site's advertising. Will in-feed ads substitute for on-site ads? Will any kind of conventional advertising work in the RSS world? Dunno. I think we're all just making it up as we go along.
Former URL: http://weblog.infoworld.com/udell/2003/06/08.html#a716