Naming websites

Once upon a time (okay, 1995), Ward Cunningham invented WikiWikiWebs. They spread all over, even slowly creeping into the commercial world. In 2001 it was thought that using one would help speed up article-writing for Nupedia. Today they are known as wikis, and that particular one has grown so popular that it is not only known by virtually every internet user, its popularity relative to other specific wikis is so much greater that to almost everyone, Wikipedia = Wiki = Wikipedia.

Wikis are a very useful type of website for many applications. Not all, of course, but many. When thinking up a name for a website using a wiki, a convenient name is “Wiki”+”topic”, e.g. Wikitravel. Of course, doing so presumably makes your website the definitive wiki for that topic, despite the reality of others e.g. World66. [hmn, upon writing this I find that these two examples have now decided to work together… cool]. You can see their relative popularity on Alexa; how much of the greater popularity of Wikitravel do you think can be attributed to its name online?

The strategy these days seems to be (1) pick a topic, make a wiki for it and (2) call it Wiki[topic]. The difference, I think, is that now the naming is very deliberate, rather than convenient. I think it is working very well, too.

Open[Topic] is the other name I wanted to mention. While there are many open sourceish projects around, it seems that people are getting better at marketing and are calling just about everything Open Something. I’m personally a strong advocate of OpenSearch, and I do think that some of its success can be attributed to the name.

Identity systems have been proposed and built for years. Marc Canter will tell you how great things would be today if we’d been supporting the Sxip technology years ago. Today it seems like the momentum behind OpenID is really going forward, and that it may indeed be poised to succeed more than any previous system of its kind. How much of its success do you think can be attributed to the name?

This post was provoked by the mention of Wikileaks as I listen to the radio.

There is no XML without namespaces

Yes, this makes two blog posts today, and yes, I’m going to talk about XML again.

I’ve suspected this for a while, but hadn’t looked into it. Thanks to Sam Ruby, I see that someone has: Who knows an XML document from a hole in the ground? shows that indeed, a lot of RSS/Atom parsers are not reading XML as XML… or at least, they’re not understanding the namespaces.

This wasn’t a problem when most feeds were bare-bones, and before Atom. Now, only a couple of years after I expected, all sorts of data and metada is starting to be put into feeds, with lots of different namespaces.

This is one of those things were if you’re a feed reader, and you don’t understand namespaces, you are broken, and need to be fixed. There’s no way around it, end of story.

That being said, I’m much more optimistic now than I was about those fixes actually happened. Phil Ringnalda’s Atom title tests really did help and pushed a lot more readers into supporting it properly. Now let’s see some real XML parsing.

What’s wrong with MSN’s RSS search

News from Luigi about RSS search from MSN leads me to think MSN Search knows what they’re doing. Or not.

They are putting RSS/Atom search integrated right in with their web search. This is good. But… they’re displaying RSS feeds as regular search results, without modification. That means that when you click on a RSS feed result, you are taken to (surprise) the RSS feed, which, most of the time, is not in a human-readable format. Hello usability? This is acceptable for a major engine to put out for average web users?? Additionally, the ‘cache’ link for RSS feed results displays a somewhat more human-readable display, but it could definitely be improved.

Virtually all, if not all RSS feeds today are representations of existing web pages. It would make a little more sense to point to those, and provide an additional link to the actual RSS feed. This is essentially what all the major RSS search engines are smart enough to do, including Feedster, Blogdigger, and Bloglines.

Actually those engines are all smarter still, since they’re indexing individual RSS items rather than whole RSS feeds as if they were a single document. That’s a huge benefit of RSS; that the individual items have been separated, and usually come with important metadata, like the date. MSN doesn’t seem to make use of this at all, although admittedly their implementation is new.

It does appear that Yahoo has got some of this right, linking to web pages (and sometimes the web pages of the individual items). However, the same does not apply to their search API, which does use RSS feed URLs as the main link for each search result, and it does not provide the web page alternative. Which leads me to the news today of Yahoo Weather in RSS. They’re even including some excellent data in there, but, they’ve defined a new namespace for some of this data, which points to http://xml.weather.yahoo.com/ns/rss/1.0, which returns a 404 now. Also it’d be nice if they labeled their namespace ‘weather,’ rather than ‘yweather.’ And I strongly suspect that there are existing weather vocabularies they may have been able to use instead.

Anyway, back to MSN Search, they’ve introduced two new syntaxes, feed:, to specify to look for RSS feeds, and hasfeed: to specify that the results are web pages that have RSS feeds. That seems okay, but the way to use the syntax is odd. For example feed: site:bbc.co.uk. It has been semi-standard for a while to use syntax like syntax:foo, as in the site: keyword used, however the new syntax seems to be syntax: by itself. Confusing. Let’s just assume that this is temporary, until there’s a web-based interface for choosing to find RSS feeds.

</rant>