Keith Devens .com

What namespaces buy you is distributed ownership. Without support for namespaces in RSS 2.0, this would have required that Dave agree to put it in the core. With namespaces, Joe didn't even have to agree to it going in wfw, it could have gone anywhere, as long as enough people seemed likely to agree on one namespace owner's version of how to do it. So at least in this case, namespaces took it from absolutely, positively impossible, to already done.

Phil, thanks a lot for your perspective. Before, not knowing why people who "get" namespaces really want them, I didn't have something concrete to consider... now I do.

The way I'd picture something like this happening in a non-namespace-enabled alternate-reality XML would be that someone would say "Hey, use the 'wfw-commentRss' tag to mean this", and if the community decided to use the tag it wouldn't matter what the owner of the parent spec thought. Just like it doesn't matter now as long as someone uses a different namespace.

So, in the case of the owner of the parent spec not putting a link to the new feature in his documentation, all the namespace seems to give you is some documentation on where you got the tags from.

The only way I see a problem arising is if the owner of the parent spec intentionally tries to sabotage the new tag by defining an identical tag for a different purpose. But again, the community would decide whether or not to support this, and in practice I doubt that that behavior would be common

Phil hits the nail on the head.

It isn't just distributed ownership. Look at http://backend.userland.com/formatsForBlogBrowsers . In the process of using RSS as an archive format, Dave Winer introduces a number of Radio specific tags, and does so i n the right way... MT or LiveJournal could do likewise.

What is really exciting is that people can form agreements and execute on them without requiring a lot of debate. Sure some dumb things will get implemented occasionally, but those will not get widely adopted, and will eventually disappear.

The problem with just using tag names is that while Joe was developing his Well-Formed Web, I was also developing my Web For Winners, and our wfw-commentRSS tag points to the URL where you can post a comment in RSS format. No way to tell which you've got when you find one in an RSS file. So we need some way to pick unique things in our tag names, something that only one person could own. Using URLs saves us having to build a separate registry for XML tag names. Unless someone steals it, only I own and control philringnalda.com, so I can call my tag http://philringnalda.com/webforwinners/:commentRSS, and nobody else would ever use that for their tag name. Be a pain to type, so I'll say once that wfw="http://philringnalda.com/webforwinners/" at the top of the file, and then just use wfw:commentRSS, and we've got namespaces.

The fact that you can sometimes retrieve something from the namespace URL that explains it is just gravy: even if I forget to renew my domain or pay for my hosting, the namespace still exists (though things get a bit cloudy if someone else re-registers it and defines commentRSS as something else in the same namespace...).

The more I think about what you've said, the more I come to the conclusion that namespaces don't solve any technical problem, but are rather more of a "social" feature. It seems that with namespaces people are likely more willing to extend a specification than they would be otherwise.

But I'm not convinced that's a worthwhile tradeoff in the complexity of XML itself. I don't think that most XML specs grow organically in the same way that RSS has. So I still wonder whether it's ultimately a good feature for XML to have, even if it might be beneficial in some cases like it probably has been with RSS.

Oops, I posted my last comment before I saw Phil's last comment...

Phil, that example is a little contrived It's obviously a "possibility", but it seems to me that the confusion that would be created in that rare case is worth avoiding the confusion that is XML namespaces

Of course I'm still willing to be convinced that this type of conflict is potentially much more common than I think, which would change the nature of the namespaces tradeoff. As a sanity check, I wanted to see if any of the different tags available in all the different namespaces people use with RSS have the same name. Turns out Dublin Core has a "title" and a "description" tag, which would conflict with the basic RSS title and description tags. But since we already have title and description elements in RSS, dc:title and dc:description are never used. And, if there were no namespaces, all the dublin core tags would have wound up being called dc-whatever in RSS anyway. So, I'm still not sure the cultural reason is a good enough one.

The other possible use of namespaces, which is more of a technical reason, is if you want to nest one type of XML document inside another, and nest another one (possibly the parent again) inside that. I headed over to the SVG spec to see if maybe they use HTML for the text inside a SVG file. It turns out you can do that but "the exact semantics of this approach are not completely defined at this time". So I question the wisdom of this type of use in general.

Maybe as XML gets older I'll become convinced that the extra complexity associated with namespaces is worth it. In any case, thank you both for your explanations, I really appreciate it.

Hmm... last possible use of namespaces I can think of:

If you have different versions of a spec written years apart that have slightly different semantics. I noticed the W3C's namespace for XHTML was 'http://www.w3.org/1999/xhtml', and it got me thinking. What if in 2010 we want to change some things about XHTML but not have to name our tags differently or come up with a whole new spec? Or maybe just change the meaning of a few tags. Changing the namespace could allow this without major disruption.

However, that also doesn't seem to do anything that a version number wouldn't already make possible, so maybe that's not such an important use for namespaces either.