It’s just data

commentRss

Matthew Mullenweg: the author of the Well-formed Web spec has changed the capitializition of the wfw:commentRSS element at some unknown point to lowercase Rss. This arbitrary decision has been codified by the validator, which now reports the millions and millions of feeds that use the previously correct capitialization as invalid

For a brief moment, I contemplated redirecting feedvalidator.org to Matt’s post.  But then I thought better of the idea.

This is not a case of “previously correct capitialization” not being reported as invalid.  This is the case of a “previously incorrect capitialization” not previously being caught by the Feed Validator.

I’ve just deployed a change, downgrading this to a warning.

Joe: I’d like to suggest that you update this page to point to Chris’s archive, and to note both the original (and preferred) spelling as well as the alternative (and discouraged) spelling.

As to content:encoded, if people can come to a consensus on to the precedence rules regarding description and content:encoded, the Feed Validator will honor such consensus.  At the present time, I believe that the best hope for a positive outcome for such a discussion would be to have it on the rss-public mailing list.


As to content:encoded, if people can come to a consensus on to the precedence rules regarding description and content:encoded, the Feed Validator will honor such consensus.

What do you mean by “precedence rule"? My "full-content” RSS 2.0 feed uses <description> as the rough equivalent of <atom:summary> and <content:encoded> as the rough equivalent of <atom:content>.

Seems to me that a good feed-reader would offer the user a preference setting: would you like to see the summary or the full post displayed?

No “consensus” required (or desired).

Posted by Jacques Distler at

Seems to me that a good feed-reader would offer the user a preference setting: would you like to see the summary or the full post displayed?

Now if only you could persuade all the feed-reader developers that your opinion was the only one that mattered. Then you could just persuade Dave Winer to add an addendum to the RSS spec to point to your comment here as the official word on the subject.

Right now, different feed-readers interpret description and content:encoded in different ways. Until someone comes up with an official set of rules on the “good” way to interpret these elements, there will be interoperability problems. The feed-validator is just warning people that the feed they’re producing may not be seen as expected by some of their readers.

Posted by James Holderness at

My "full-content” RSS 2.0 feed uses <description> as the rough equivalent of <atom:summary> and <content:encoded> as the rough equivalent of <atom:content>.

Just last month, the current chair of the RSS Advisory board stated: I don’t think I’d count on RSS clients treating description as a summary and content:encoded as a full weblog post.

The feed-validator is just warning people that the feed they’re producing may not be seen as expected by some of their readers.

Furthermore, I’m confident that the solution that the Feed Validator suggests would lead to more aggregators (including — if I don’t miss my guess — Dave’s own NewsRiver) seeing Jacques’s “full-content” RSS 2.0 feed (which I can’t find, BTW) as truly being “full-content”.

Posted by Sam Ruby at

Burningbird: Scrambled Eggs

It’s Easter morning where I am. The storms of last night were mild in our area, and the sun is up, the birds singing, and a nice breeze blowing through my windows. The trees are mostly green, except for the dogwood, with it’s pink and...

Excerpt from Gregarius at

Just last month, the current chair of the RSS Advisory board stated: I don’t think I’d count on RSS clients treating description as a summary and content:encoded as a full weblog post.

From Susan Kitchen’s point of view, a choice of precedence rule doesn’t matter, as she was really hoping that her feed reader would display both <description> and <content:encoded>.

Roger’s response was: I don’t know what the precedence rules are. Which speaks to your issue, but not to hers.

My point is that this is a user-interface issue. The meaning of <content:encoded> is clear: it’s the full-content of the weblog post. A plain reading of the RSS 2.0 Spec is that <description> is some sort of summary of the weblog post. (One might argue that a plain reading of the RSS 2.0 Spec is, like a plain reading of any Gnostic text, a category error. In this instance, I don’t think one needs to take so drastic a stance.)

How these should be displayed (if both are present) is a matter between the feedreader and the user. Just like the decision of how to display  <atom:summary> versus <atom:content>.

Posted by Jacques Distler at

RSS and content:encoded

Sam Ruby is looking for consensus on the handling of content:encoded and the description entry in RSS feeds. One se of thinking is to treat the description as a summary, and the content:encoded as the full text: As to content:encoded , if people...

Excerpt from Smalltalk Tidbits, Industry Rants at

The New Internet Jerry Springer

So it should have been a warning instead of an error. But Sam Ruby took the software and fixed that. But the New Internet Jerry Springer episode list is starting to shape up: Matthew Mullenweg: The Feed Validator is Dead To Me The latest in their...

Excerpt from Rambles of a University Systems Manager at

... would lead to more aggregators (including — if I don’t miss my guess — Dave’s own NewsRiver) seeing Jacques’s “full-content” RSS 2.0 feed (which I can’t find, BTW) as truly being “full-content”.

You can’t find it because I don’t advertise it anymore. But it still has plenty of subscribers (who, I assume, somehow manage to see the full content). On the other hand, feedreaders which don’t support <content:encoded> will find it functionally-identical to my summary-only RSS 2.0 feed (which I do still advertise).

Call me crazy, but I assume that <content:encoded> is more widely implemented in feedreaders than is Atom 1.0.

Posted by Jacques Distler at

Call me crazy, but I assume that <content:encoded> is more widely implemented in feedreaders than is Atom 1.0.

And you would be right (and yet, as with all things RSS, subtly wrong).

Which is not surprising, since mod_content has been around for more than 5 years.  The content:encoded element predates Atom 1.0, Atom 0.3, Echo, Pie, six incompatible specifications all calling themselves “RSS 2.0”, RSS 0.94, RSS 0.93, and very nearly — but not quite — my entire relationship with the woman who is now my wife and mother of my two kids.

Let’s check back in another 5 years and see how Atom 1.0 support is coming along, shall we?

Posted by Mark at

Jacques, I’m not going to call you crazy.  Furthermore, I’ll state that your “full-content” RSS 2.0 feed is valid, and despite having a number of issues, undoubtedly provides value to a number of aggregators.

Now, let’s back up a bit; though I will state that this entire conversation feels weird as I know your opinion of RSS.

A plain reading of the RSS 2.0 Spec is that <description> is some sort of summary of the weblog post.

Actually, a plain reading of the RSS 2.0 spec is that <description> is either some sort of synopsis or contains the complete text.  (An ambiguity that causes Technorati angst)

Now, if you were to tell me that you had separate summary-only and full-content RSS 2.0 feeds, I would assume that these terms corresponded to these two options.  However, this is not what you have done.  You have instead chosen to disadvantage a small number of consumers who don’t have built-in support for content:encoded.  This is not theoretical.  I know that such readers exist.

Let’s assume that this is not a political statement on your part.  Instead, this feed seems to be uniquely tailored to the set of consumers that (1) do not support Atom 1.0, (2) do support content-encoded, (3) provide an option for selecting between summary and content that somehow is preferable to choosing up front between your summary-only and complete-text feeds, and (4) understand that you intend that this content be treated as XHTML and that your item links are to be used as the base for resolving any relative URI references.

If this is not the empty set, it certainly has to be asymptotically approaching such.

But, again, I’ll readily agree that you have a feed that undoubtedly is useful to many.  It likely would be equally as useful to most — if not all — of these people, and more useful to others, if you followed the suggestions in the solution section of this message; and furthermore the result would not run afoul of Dave Winer’s repeated requests as to how RSS 2.0 should be used.

Posted by Sam Ruby at

Actually, a plain reading of the RSS 2.0 spec is that <description> is either some sort of synopsis or contains the complete text.

And the content model is either plain text, or entitity-encoded HTML.

<content:encoded> is unambiguous in both regards and is (I thought) universally supported. <xhtml:body> would have been a better choice for my content, but does not seem to be widely supported.

Now that you tell me that there are RSS 2.0 clients that do not support <content:encoded> (at all), I may have to revisit that.

and despite having a number of issues, undoubtedly provides value to a number of aggregators.

I am certain that the number of feedreaders that can handle my RSS 2.0 full-content feed without data loss or other serious breakages is rigorously zero. (Which is why, now that there exists a better alternative, I no longer advertise it.)

I am not sure there are any Atom 1.0 clients that handle my full-content Atom feed correctly, either. But it is, at least, conceivable that some might.

Thunderbird was the only client on James' list which did not support <content:encoded>. On the other hand, it does support Atom 1.0. A future version might even display my Atom feed correctly.

But enough about me...

The main point, that I was unaware of, is that there are actually RSS 2.0 clients that do not support the content extension. This isn’t a “precedence question” (since, according to Jame’s tests, all of the clients which do support it will display <content:encoded> in preference to <description>). It’s a “does not support this extension at all” question.

As Mark points out, RSS is a neverending source of surprises.

Posted by Jacques Distler at

The main point, that I was unaware of, is that there are actually RSS 2.0 clients that do not support the content extension.

Here is a very recent instance proof of an aggregator that (as currently configured by default) prefers an empty description element over content:encoded, evidently much to the surprise of the user of this tool.

In the logic of RSS, it is not the spec’s fault.  Or the user’s fault.  Or the user’s tool’s fault.  It is the feed’s fault.  As it is anti-interop.

Posted by Sam Ruby at

The main point, that I was unaware of, is that there are actually RSS 2.0 clients that do not support the content extension. This isn’t a “precedence question”

Perhaps it wasn’t clear in my message, but for some clients that do support content:encoded it’s the order of elements which determines whether content:encoded will be chosen above the description element. I think that’s the precedence issue that Sam is referring to.

Also, I should mention that Thunderbird’s lack of support for content:encoded is apparently a bug that will be fixed (or so I’ve been told). However, to counter that, I have since encountered other clients that don’t support content:encoded either.

Posted by James Holderness at

Atom Torture Test

Four tests of Atom feedreaders.... [more]

Trackback from Musings

at

Sam: I’ve updated the WellFormed Web page as you suggested.

Posted by Joe at

Sam Ruby: commentRss

Important discussion in the comments. Tags: atom, rss, syndication, feedtools...

Excerpt from Ma.gnolia: Recent Bookmarks in Syndication Development at

wfw namespace elements

The wfw namespace, [link] contains multiple elements. As more are added in various places I will endeavor to keep the list here updated. wfw:comment The first element to appear in this namespace is comment. This...

Excerpt from The Well-Formed Web at

Add your comment