Who Loves Namespaces?
The discussion over namespaces in RSS 2.0 isturning outto be a very instructive study for those of us whobuild XML infrastructure, training courses, and productsfor developers. I hope that anyone who makes a living catering to XML developersis paying attention.
Most XML “experts” would consider it insane to attempt using XML for interop without using namespaces. However, this is exactly the subject of the current debate over RSS 2.0. Dave has listed the three possible options for RSS 2.0 use of namespaces.
At first glance, it seems like option 2 (require namespace on all elements)is the obvious choice. Reading Sam Ruby’s “Gentle Introduction to Namespaces” explains why. An element with a name like RSS’s “Title” is common enough that you are virtually guaranteed to have name collisions in large scenarios if you fail to disambiguate somehow. For example, if I want to attach someone’s iCard (used for contact info by Outlook, Netscape, etc.) to the header of their RSS feed, how will I know which “Title” element refers to the person’s job title and which refers to the title of the blog item?
But before we make any decisions, let’s make sure that namespaces are really so gentle as Sam’s introduction implies. The first hint that things might be more complicated for RSS 2.0 comes from anxml-dev thread spawned by Don Box and Aaron Skonnard, titled “Default namespaces are evil!”
The thread goes right to the heart of Dave’s other two options: 1) Nothing has a namespace, or 3) Namespaces are optional. Since RSS 0.9x versions all used option 1, it’s rather difficult to achieve any sort of backwards-compatibility if RSS 2.0 adopts mandatory namespaces. But, what we learn from scanning the xml-dev thread is that any use of blank namespaces is risky. It seems that RSS 2.0 is in a difficult position.
Now, it would be foolish to make a decision based on some disorganized rants about the evils of default namespaces, so let’s look for something more comprehensive and objective. Aaron Skonnard’s “Understanding Namespaces” offers some general discussion regarding issues with default namespaces, andDare Obasanjo drills into specifics, exhaustively covering the potential pitfalls of namespaces in XSLT and XPath, and in XML Schema. Well, now we have confirmation that RSS 2.0 is in a difficult position!
But wait! It’s worse! While RSS 0.9x versions stuck everything in a null default namespace, RSS 1.0 forked off to be based on RDF 1.0. RDF uses “RDF Namespaces”, which look seductively like XML Namespaces, but are completely incompatible in the most annoying ways. “RDF Namespaces”, just like “XML Namespaces”, are used to disambiguate local names, but the disambiguation rules are different.
So, who’s fault is it? It is easy for the XML “elite” to blame the user when confusion arises. But this is a cop-out, and in this case, we are talking about people who are at the cutting edge of XML. Dave Winer a clueless user? I doubt it. The “RDF Lobby” a bunch of confused newbies? No way. So how did all of these smart people end up in such a mess? And if RSS has evolved this way, what hope does the average IT organization have?
I’m not saying that evolving XML schemas is a hopeless task, but I think the industry participants need to pay way more attention to this problem and give our customers better overall guidance. Customers shouldn’t have to be having the sort of debates that RSS 2.0 is having. If they do, we failed.
And none of thissays that XML itself is a failure in RSS. There is an old saying about “code talks”. regardless of the fact that RSS 0.9x and RSS 1.0 are completely incompatible, there are scores of implementations out there which handle both just fine. And there are already a number of apps which handle RSS 2.0. The specifications exist so that people can write interoperable apps, and so far they have been quite successful at this. Obviously things are going to be more difficult when people start trying to mix various XML vocabularies with RSS, such as the iCard example above. But maybe that’s not the highest priority for the customers of RSS.