James Robertson wrote"I've posted a few times now ( try this site search) - as you can see, I'm skeptical about the motivations, and cynical about the benefits. Had they stuck to:Providing a standard posting formatComing up with a best practices document for RSS we might have seen something useful. Instead, what we have now is a format that has (other than a couple of pointless tags, like subtitle and contributors) all the functionality of RSS 0.91. Soon, this effort will spawn modules that look astonishingly like RSS modules, but with different tag names. Think about this from two standpoints - one, the end user of a news aggregator. Does necho provide said user any benefit over RSS? The sad truth is, no, it doesn't. In fact, it provides a user experience that looks a lot like an RSS 0.91 feed. Two, how does this affect aggregator authors? It's another format (and, if I'm correct, another set of modules) to support. Does it relieve us of the burden of supporting RSS? No, it doesn't. Does it gives us, as aggregator authors, any information we currently don't have that we could make use of for the end user? No, it doesn't. So, as Mark Bernstein so eloquently put it, this is an unfunded mandate for developers."
"I've posted a few times now ( try this site search) - as you can see, I'm skeptical about the motivations, and cynical about the benefits. Had they stuck to:
Feedback for designers "feed" is not a very unique name, and if another format were to come along with the same top level element we would not be able to write a format driver for it. Our architecture keys off the top-level element. I suggest changing the top-level element to indicate the format, and also add a version number so that aggregators can have an idea of what spec the content provider is using. I imagine Radio is not the only aggregator that would like to key off the name of the top-level element.