Namespace undefined
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.
Actually, there's a better way to do this (which does not use the dangerous local-name). See http://radio.weblogs.com/0106548/2002/09/28.html#a86.
Posted by Ziv Caspi at
I fail to see how that example is applicable to XSLT without using local-name(). Can you show me an example style sheet?
Posted by Dare Obasanjo at
I changed "very difficult" to "more difficult". Before:
<xsl:template match="rss2:item / rss2:title">
after:
<xsl:template match=" * [ local-name() = 'item' ] / * [ local-name() = 'title'] ">
Posted by Sam Ruby at
Perhaps I was too hasty, based on Simon'stesting, I should have said essentially impossible.
I feel more strongly than ever that the correct solution is to identify the namespace for each element.
Posted by Sam Ruby at
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.
Posted by Dare Obasanjo at
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.
Posted by Phil Ringnalda at
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
Posted by Simon Fell at
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.
RSS is growing up. :)
I love this game...
Posted by Dare Obasanjo at
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.
Posted by joe 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.
Posted by Simon Fell at
Echoing Simon's sentiments. The fact that a namespace name is the default namespace at some point in the XML document is NOT significant in any way.
Posted by Dare Obasanjo at
Yes, my bad, I was too loose with my terminology. Aggie is keying off the local name of the root element and the namespace of said root element.
Posted by joe at
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?
Posted by Phil Ringnalda at
Phil,
No, Aggie doesn't *need* a namespace on the core to operate, Ziv has a nice description of how Aggie handles things.
"So, a compelling benefit of a namespace for the core, and not just for extensions?"
I guess when it comes to Aggie I can't give you one.
Posted by joe at
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.
Posted by Dare Obasanjo at