Keith Devens .com

Wiki URLs

Here I go again. Now that I'm so happy with how my weblog URLs work (I should never have to change them again, whoopie!), I'm moving on to my wiki URLs.

There are a few basic organizing principles of web content. The most basic principle I've come up with is that of dated versus undated material. Weblog posts are clearly dated. Therefore, there should be a date in the URL. Period. Which is why my weblog URLs work the way they do.

Press releases are dated. However, since press releases are a rarer thing than weblog posts, it's often unnecessary to have a full date directory structure like you'd want with weblogs. So a press release URL of something like domain.com/press_releases/2003-06-19 is reasonable. The point is that press releases are dated, and that should be reflected in the URL.

Articles are often dated. Their content is created on a certain date and apart from small updates or corrections the content is usually left alone. If a major update is done to the article, it'd typically be released as a new article with a new date.

The question you answer when you ask whether something is dated is this: "Is this content allowed to expire?" Or, whether it's ok if what the article says becomes "wrong" or out of date. A company could cease to exist, yet the content of a press release is still "valid", though it's superceded by what happened afterwards, because the press release is clearly dated. The press release isn't modified to say "By the way, this company doesn't exist anymore".

Weblog entries aren't updated either, except possibly to make a small correction, or to point to new content that supercedes the old.

Now, there are other types of content that aren't dated. The homepage of a site always has to be current. Main content pages should always be current. If something on a main contact page is inaccurate or out of date, it's simply wrong, even if it was right when the page was written.

Wiki pages fall into this category. A wiki page should always be current. Therefore there should be no date in the url.

The other primary organizing principle of web content is named verses unnamed. Not everything must to be named - usually, especially with database driven content, everything will have an ID which can serve to uniquely identify the resource. However, while names aren't necessary, they can be very useful in making it clear what the content of that resource refers to. You can use both keithdevens.com/weblog/archive/2003/Jun/20/WikiURLs and keithdevens.com/weblog/archive/2003/Jun/20/3985 to refer to this post. But the name is helpful giving a short mental anchor into the content of the post.

Wiki pages are unique, however, in that the name contained in page's URL is actually the title of the page as well. It's part of wiki simplicity, and is part of why wikis work so well.

Most wiki URLs contain names are just squished together words using StudlyCaps, BumpyCaps, CamelCase, what have you. The word comes to represent some concept - WikiWords are often neologisms. In fact, Wikis are often fertile sources of creativity in language. Today I just learned what a WikiBadge is.

The problem is, while some WikiWords refer to actual concepts that "belong" to be in StudlyCaps, like StudlyCaps , WikiBadge, etc. (surf around Wiki for more), many page names don't work well as StudlyCaps. So, PhpReference isn't a "new" thing, it's just a PHP Reference. So it'd be nice if the URL didn't look like it was creating new concepts all the time. And having every linked page be in StudlyCaps just isn't friendly to the reader. It's harder to read, and it keeps the wiki from looking like a normal web page.

So just now I tried creating a page with spaces in its name in my wiki and it worked just fine. The only thing is, plusses in a URL are ugly. I really like how the UnrealWiki does it. Page URLs have underscores instead of plusses for spaces. When the title of the page is rendered, underscores are replaced with spaces, and when a link is made in the text of the page it can be entered with spaces and when the page is actually rendered the spaces are automatically replaced with underscores.

So, I have two choices. I can either do no special processing on the URLs besides normal URL encoding, which would wind me up with plusses in URLs for pages with spaces in their names, or I can forego having underscores in wiki page names (not a big sacrifice) and convert all spaces to underscores, and on rendering and name resolution convert underscores to spaces. Again, I like how the UnrealWiki does it, so I may follow suit.

Ahh, this was relaxing to write... nothing too important or hard to think about

Oh yeah... comments?

See Also: http://www.keithdevens.com/wiki/WeblogUrls