Camel Vs Non Camel

There seems to be an eternal debate in the Wiki world concerning links. Should they be with capitalized letters LikeThis or with some other method such as brackets [like this]?

Against CamelCase:

  1. CamelCase is a headache - it's simpler to use square brackets
  2. CamelCase leads to problems solved by UgLy links
  3. CamelCase makes links incorrectly, such as McDonalds
  4. CamelCase words are hard to form in some languages (e.g. Croatian)
  5. CamelCase phrases in English can be harder to comprehend to non-native readers

For CamelCase:

  1. It's simple to use
  2. It promotes AccidentalLinking by reducing the WikiWord namespace
  3. No ugly punctuation in the plain text

See also WikiNameAdvantages vs. WikiNameDisadvantages.


An alternative:

A wiki should create links everywhere it can, leaving the reader/editor to inhibit those that are inappropriate. If there is a page called ThisExample and the text contains

... it can be seen that this example is one of ...
then the link will be made.

This gives:

  1. No special use required
  2. AccidentalLinking and connections is the norm
  3. No UgLy capitalization - the plain text is natural
  4. No syntactic noise

Some details need addressing:
  1. Inhibit links - for multi-word links one could use a double space between the words. If it's a single word link one could put a leading underscore ("_")
  2. In BrianIngerson's Kwiki, linking can be inhibited by prepending a ! (exclamation point) to the potential link. This works with URLs as well.
  3. Create a page of aliases with pairs of entries. The first is a page that might get mentioned, the second is the page that gets linked to.
  4. Use a greedy algorithm to match the longest pagename possible
  5. For overlapping matches use some algorithm to chop up the overlap.

See also: GaGaParser, http://www.usemod.com/cgi-bin/wiki.pl?DynamicLinkSuggester


If the issue is just one of links being created when not wanted, (PhD not being a link), then changing the linking syntax is not the solution. The simplest thing to do is tweak the CamelCase parser to recognize an additional simple marker that indicates the word should not be a link. SixSingleQuotes achieves that goal.


SixSingleQuotes (i.e., a null string in triple quotes) also messes up the apparent formatting on some browsers (notably, NetScape 4.5); it puts in some pixels of whitespace where the quotes were. The effect is especially noticeable when text is italicized. It's also a lot of typing given the intent. People here are complaining about adding two characters to make a link, but apparently have no problem adding six to prevent one.

[ ] links have the very clear advantage of making it much easier to avoid UgLy-ness, since case sensitivity is no longer at issue. The main argument put forward in favour of CamelCase (as I read it) is that it shields you from having to think about the task of linking, or the name of what you are linking to. But to me, the fact that people produce UgLy page names is evidence enough that it doesn't work that way.

Avoid UgLiNeSs? by having links case insensitive.

I like the idea presented above, on a first reading, to link everything that exists (even through spaces, and without bracketing characters) and concentrate on the link-prevention mechanism. But it seems to me that there are problems here. What if someone makes a page with a title like "the"?
  1. Remove the page called the
What if I have "foo bar baz" in my page text, and both "FooBar.txt" and "BarBaz.txt" are in the database?
  1. Answered above.

In PhpWiki, the [] syntax is extended so that you can have link text which does not match the page name. The syntax is [link text | PageName ] (or was it the other way around?) This strikes me as occasionally useful, but perhaps a bit dangerous (information-concealing). The fact that I can never remember (with confidence) the order of arguments is another problem.

The main problem I have with CamelCase links, though, is that it becomes hard to deal with aliases, and/or rework your wording for grammatical reasons. This problem isn't really addressed by [] links either, although PhpWiki offers a (hacked-feeling, IMO) solution with the [|] syntax.

This is what I mean: It's bad enough to remember to use SixSingleQuotes in, say, "ObjectOrientedLanguages" (so that there is no duplicate page). But if I want to refer to RefactorMercilessly, and the grammatically correct phrase in the context of my sentence is "mercilessly refactored" or "merciless refactoring", then I'm out of luck. I don't (and the WikiCommunity seemingly agrees with me) want to have to make a trivial little alias page for each alternative, but remembering which of the pages is the one that actually exists can be troublesome in some cases.

I have worked out a solution for the problem for ZincWiki, which plays off the idea of PhpWiki's [|] links. Basically, you can use | as a delimiter within [] (as link indicators), and every other "item" is ignored when determining what page is linked. There's a bit more to it than that, which I'll describe on the ZincWiki page once I get back to implementing things.

-- KarlKnechtel


Anyone tried using [[page name] alternate text] instead of [[page name | alternate text]]? Seems like that might make it easier to remember which goes first. Also, it follows somewhat logically from the [[page name]] syntax.


Let us say I write a page and at one point I want to quote a song by Michael Jackson. But I don't know that there is a page on Michael Jackson here. So I write Michael Jackson. But the computer knows there is a page on Michael Jackson so it will automatically create the link by putting Michael and Jackson together. Is that what you are talking about? An automatic creation of links by the software? (or to be more precise a re-creation by the software of a link that already exists)

  1. I don't know what you mean by "create the link by putting Michael and Jackson together". It doesn't change the text on pages, it just recognizes that links should be made.
  2. However, yes, it should create the links automatically.

But if we had a page called IloveMichaelJackson?, would the software create that link when the user typed just Michael Jackson?

No, it would require the text "I love Michael Jackson" to get that link

And if down the line after I type in my text the Michael Jackson link is created. Will my text be changed sort of retroactively?

Your plain text is never changed - I don't understand what confusion you have that makes such a question possible. If you create the text "... Michael Jackson ..." and the page MichaelJackson does not exist, the link is not created. If later the page is made and then you look at the original page, the link will be there.

So it never supplies an undefined link then? -- KarlKnechtel

Yes, CamelCase is still recognized and forces a (potentially dangling) link.

I've given it some thought, and I'm satisfied (I think) with the approach I intend to take with ZincWiki. It borrows a bit from this idea actually :)


Why not have both camel and non-camel and let the user select the one they want? Or support both syntaxes? This works for UseMod and WakkaWiki.


Historical Note. Some people wonder why they can't make anything they want be a link, especially when they can make anything, including images, be links in html. Some insight may be had by understanding that I was not searching for a link formatting syntax when I created wiki. Rather, I was looking for specific characteristics for whole pages, including their titles. I was pleased when I realized that the titles I wanted could be recognized with sufficient reliability despite my adding no additional markup whatsoever. -- WardCunningham


An additional, subtle, pro:

Thanks to CamelCase new concepts are popularized. Here is why:

When a couple of words (or slightly more) go together well and if the underlying concept is successful enough, then the CamelCase name for the concept will pop up frequently and chances are that it will become an idiom.

CamelCase is an example of this.

Having names for things is a good thing; it structures the mind and facilitate communication. Existing names are already overloaded with meaning. CamelCase open a new name space for CamelNames?.

You may agree that the success of acronyms is another indication of the deep need for new name spaces. So, help fulfill that need and promote CamelNames?. :-)

BTW: Do we remember how we used to describe a name in CamelCase before CamelCase became so widely accepted? I discovered the name "CamelCase" while browsing www.c2.com, the original Wiki. That way... despite having been exposed to SmalltalkLanguage years before (where I believe CamelCase was used a lot for the first time).

An additional benefit of CamelCase is that as wikis becomes increasingly popular, it will become possible to use a CamelName? in a mail message. People will understand that one is referring to an already defined concept that they can find information about in some wiki.

Now, if you want to promote CamelCase names, provide a feature whereby one can easily provide a CamelLink? to a WikiPage in an external wiki and then you get another WWW (WorldWideWiki). See also InterWikiLinks, on Meatball (http://usemod.com/cgi-bin/mb.pl?InterWikiLinks)

-- JeanHuguesRobert

PS: If you want to support [[such links]], make it possible to have CamelCase links too (at the same time).


See WikiDesignPrinciples, WikiWordsConsideredHarmful


EditText of this page (last edited June 4, 2008) or FindPage with title or text search