0xDECAFBAD:
And your conclusion would likely be correct. I
disagree. To help illustrate the point, I've made a change to
the namespace in my rss2
feed. Is it valid according to the specification?
I don't know. If so, it would be very more
difficult to write an
XSLT based aggregator which could handle the potentially
infinite number of possible namespaces apparently permitted by the
spec.
RSS 1.0 has been free of such
discontinuities. Title has always been
required. The namespace has always been
specified. As you said, This is an issue of versioning,
understanding the technology's implications, and
reverse-compatibility
Similar to the statement that I said about the change in title, adding
namespaces to the RSS 2.0 spec was a was a bold step that may break
a number of assumptions that tools were making, but mades possible
a large number of
innovations and creativity.
Why would it be "very difficult" to write an XSLT based aggregator that ignored namespaces in an XML document? All it would take is judicious use of the local-name() function.
Simon's test simply shows that current aggregators can handle multiple versions of RSS in varying degrees.
If you throw in the ability to add modules then using local-name() alone is not enough but this still doesn't make it difficult since Ziv Caspi's suggestion could just be used.
Assign some variable to the namespace name of the root element and use that along with local-name() to determine the RSS elements you're interested in.
What am I missing, that makes it worth breaking virtually every implementation in existence, just to put a namespace on the core elements?
The breakage from defining something other than "" as the default namespace for RSS is nothing compared to the breakage that results from the implication that, if the core elements have a namespace, then they don't have to be in the default namespace. I threw together a feed last night with <foo:rss>, etc., and it was either refused by, or wreaked havoc with, every single reader and parser I have. Unless you say the core elements have to have a namespace, but it has to be the default namespace, it's equivalent to saying that 2.0 should be completely incompatible with 0.9x and everything that has been built to consume it. Not a bad idea, since we can dump all the cruft that nobody wants, but will anyone actually use it?
The only thing I see that we lose if the spec says "the core elements have to be in the default namespace, and further that namespace has to be "", so don't even bother declaring it, they aren't namespaced" is that we can't embed RSS in files in other XML formats that have so many elements in the default namespace that it would be a pain to add a prefix to them all. The only one that seems likely to me is XHTML, and as I remember Ben Hammersley suggested that a while back and got dumped on so severely that he yanked the proposal within a day or two.
You still get all the benefits of putting extensions in namespaced modules, which readers will generally treat just like they do 1.0 extensions: they'll ignore them.
So, what am I missing? It's not a rhetorical question: this is well outside my field, so there's probably a reason why such a sensible-seeming idea won't work, but I don't know why not.
but phil, this is already an issue as RSS 1.0 uses namespace qualified elements, and i've seen real feeds in the wild that don't use a default namespace for the rss elements, but prefix all elements. Aggregators should already be supporting this [but they don't appear to very well]. For example, for an example see Don's feed http://www.gotdotnet.com/team/dbox/rss.aspx
Backwards compatibility is the scourge of the software industry.
Claiming "backwards compatibility" and complaining about having to rewrite existing applications (in this case simple applications like news agregators) is a primary mechanism used to impede progress and create a culture of hacks, cruft and inconsistency in a technology.
Phil, The big benefit I get from a default namespace is that it lets me determine the format of the file in an unambiquous manner.
For example, a new group could spring up tomorrow with a new format, say it's called XRSS 2.0, that has the same basic structure as RSS 2.0 but drops the new elements Dave just added, such as pubDate, guid, etc.
Now I can't look at the version attribute to tell me what type of file it is. But if this theoretical XRSS 2.0 put it's elements in a default namespace, for example: http://purl.org/XRSS/2.0, then I could look at the default namespace declaration to determine which type of file I am looking at.
Joe, i hope you mean the namespace of the root element, not the default namespace. You shouldn't rely on the defaultnamespace for anything, but rather look at the namespace name & localname of the root element.
And do you need to know when you hit the root element whether you've got 2.0 or a 0.9x version? If all you are looking for is channel/title, channel/link, item/title and item/link, would it actually matter whether you were ignoring "":textinput or "backend.userland.com/RSS2":textinput (or "foo.com":baz)? If someone wanted to do a validator that validated by 0.9x/2.0 version, they would need to know whether or not comments was a legal element, but since they're already screwed for the 0.91/0.92 differences, they can be screwed the same way for 0.92/2.0.
If Aggie can't manage 2.0 without a namespace, say so, and I'll change my tune, since it's my main RSS reader these days, but if it can, with no loss, and that will save a thousand naive regexes and non-namespace aware parsers, it just seems cruel to break them for no benefit. Especially since I support a lot of the users of things like that, people who copied and pasted something from an article from 1999 and were delighted that it worked, since they had no idea how it was working. They're mostly very nice people, and I don't approve of baffling them and breaking their toys just to make a spec seem more elegant to us.
So, a compelling benefit of a namespace for the core, and not just for extensions?