One of the many bones of contention in RSS is the introduction of new elements that duplicate the purpose of existing elements. For example, many feeds use content:encoded in the place of description. Is it better to embrace existing elements, or to extend the format with similar elements?

What is the motivation for using elements defined in extensions in the place of standard elements? A few things come to mind:

• The standard element is not specified rigidly enough. For example, does description contain plain text or escaped HTML? If one encounters something that looks like an HTML tag or entity, how should it be displayed? For example, should "&" be displayed as "&" or as "&"? By using an element defined in an extension, this ambiguity can be overcome.

• The standard element is defined too rigidly, or not as one desires. For example, in RSS 2.0, the author element must contain an email address. What do you do if you just want to put your name there? Many opt to use dc:creator instead.

• You believe that the extension is philosophically better than the standard. Some people feel that Dublin Core, as a standard that is used in many contexts other than RSS, is preferable to standard RSS elements, because its use helps feeds mesh into a larger world more smoothly.

Are these good enough reasons to go with the extension? Some would argue that it's always preferable to go with the standard rather than an extension that duplicates it. I would argue that it all depends on your goals. If your primary goal is to be compatible with the highest possible number of RSS clients, then the standard is probably the way to go. When the day comes that more clients support content:encoded than interpret description the way you want them to, then it will be time to switch to content:encoded. I suspect that that day is not here yet.

If you're willing to sacrifice some compatibility to ensure that you can do things they way you want, like specifying the author's name without an email address, then use the extension. If you want your content to be integrated into a system that speaks Dublin Core better than it speaks RSS, go with Dublin Core. If you want to exert whatever influence you have to try to get more people to use Dublin Core, use Dublin Core.

And if RSS purists yell at you for it, tell them to mind their own business. They're free to pursue their own goals, but you're free to pursue yours too.