It’s just data

RSS moderation

Dave Winer sees two groups with different needs.  I don't see the needs as being incompatible, but I do see two groups with different blind spots. 

The proponents of RSS 1.0 appear to be so enamored of RDF that they see the added complexity of an additional ,and somewhat redundant, sequence of items as acceptable overhead.  Rael refers to this as the RDF Tax

The proponents of RSS 2.0 appear to have such an aversion to RDF that, despite claims that the goal is simply to document current practice, no consideration appears to have been given to the fact that admin::generatorAgent is used out in the internet.  Instead RSS 2.0 incorporates a generator tag into the core.

My view aligns with Mark Pilgrim's.

Hey Sam, to be fair, you'd have to take into account that RSS 2.0 calls for support of namespaces. Your post doesn't do that.

Posted by Dave Winer at

I have praised the addition of namespaces on more than one occasion.

However, I fail to see how that supports the thesis that there are two groups with different needs.

Posted by Sam Ruby at


Thank you for adding support for namespaces to your 2.0 proposal.

I also agree that imposing an 'RDF tax' is unnecessary.

However, why are you adding new optional elements to the core spec, especially ones that duplicate functionality in existing 1.0 modules?

Posted by Michael Bernstein at

I presume Dave is doing this because some people dont ever want to use namespaces. As long as such tags are optional, this dosent hurt anyone, just dont use them. It just makes RSS 2.0 more complete without namespaces.

Personally, I'm more likely to use admin:generatorAgent rather than the generator tag. But I fail to see why people cant just accept that generator is an optional tag and get on with using namespaces the way they like.

Posted by Rahul Dave at

When I, as a budding and naive RSS producer, want to add information on the software creating my feed, now I have to choose between 'generator' and 'admin:generatorAgent', not to mention the option of using both. Using both also raises the issue of which tag has precedence to an RSS consuming app.

Issuing clear guidance in the spec on this issue would be good, but to eliminate opportunities for confusion would be better, IMO.

I understand that for reasons of backward compatibility, existing optional tags can't simply be removed from the spec (though they could be deprecated), but why add more confusion, when it doesn't seem to be necessary?

Posted by Michael Bernstein at

This discuission reminded me of something I read a long time ago regarding optionality in specifications.

You can read it here
under the heading "Low-Fat CMIP"

Whilst that particular discussion relates to network management specs, many of the principles would seem to apply here too.

Optionality is not always a good thing :-)

Posted by Optionality considered harmful ?


RSS precedence rules

On Mark's and my todo list is to more precisely distinguish between things that are outright illegal and things that are merely bad practice. While such duplication is not clearly illegal, there are enough questions on the precedence rules between item... [more]

Trackback from Sam Ruby


um hey, just give us something us little mouses can follow ...

Posted by dj Machomaus at

Add your comment