PermanentAnchor

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Permanent anchors allow other people to link to a particular anchor on a page. The link to that place will remain valid, even if the anchor is moved to another page, unlike normal name anchors as used in HTML.

See also PermanentAnchorDiscussion for the discussion that lead to this page.

Description

Normal NamedAnchorsInWiki depend on their host page for enough context to be resolved. For instance, the anchor #diary does not have meaning without its associated host page: SunirShah#diary. While limiting the scope of anchors to their local context is expected and desired--consider the potential conflict with AlexSchroeder#diary--this does lead to certain drawbacks when editing. You may end up moving an anchor off one page to another, thus breaking all the links to it from other locations, both from within and without the wiki. For example, Sunir has a tendency to drop anchors throughout his diary, such as #amsterdam for the entry related to his visit to Amsterdam. However, SunirShah#amsterdam no longer exists as the diary entry has moved to SunirGoesToEurope?.

A permanent anchor on a wiki is much like NamedAnchorsInWiki, except that these anchors do not need a host page to be found. They exist in a global context, much like page titles themselves. In fact, two implementations are possible, here:

Visiting a permanent anchor is a special action, therefore permanent anchors live in a second namespace different from the page namespace.
Permanent anchors work like a PageAlias with the additional capability to refer to a position within the page. Pages and permanent anchors share the same namespace.

Permanent anchors provide a very interesting new structure to wikis. Whereas the PageDatabase provides a top-down organization of the contents of the wiki, organized into discrete chunks around each page name, permanent anchors provide a bottom-up organization of the contents, organized in fluid singularities. The extra flexibility they provide may allow for untold new structuring conventions, including possibly better WikiLogs.

Syntax for Pointing To Permanent Anchors

As pointed out above, links to permanent anchors can look just like ordinary links to pages, if they share the same namespace.

If they live in a second namespace, some sort of syntax is required to denote a link to a permanent anchor. From their similarity to page titles, it may be good to co-opt the LinkPattern syntax for a PermanentAnchor by using a leading number sign followed by a page name: #LinkPattern.

This syntax could coexist with "real" local anchors such as #diary. The only constraint is that the real local anchor names may not match the LinkPattern.

Another potential syntax is ?LinkPattern since this reflects the query part of the UniformResourceIdentifier that is a critical part of the interface of most wikis. Of course, this requires that the PermanentAnchors share the same namespace as the rest of the PageDatabase, which is an innovation from OddMuse.

Perhaps a more obvious syntax is better. OddMuse formerly used [##anchor].

URL for permanent anchors

An initial idea was to pass the #LinkPattern form directly to the script, but this is dangerous. The url http://usemod.com/cgi-bin/mb.pl?#SunirGoesToAmsterdam not only violates the RFC for UniformResourceLocators but the fragment #SunirGoesToAmsterdam is to be used by the user agent, so the server and the script might not be able to retrieve it depending on the behavior of the user agent, the server, proxy, and so on.

The less attractive url scheme http://usemod.com/cgi-bin/mb.pl?action=browse&anchor=SunirGoesToAmsterdam has disadvantages that it is cumbersome. If the PermanentAnchor system is meant to be a resource, it should be as easy to use as the normal LinkPattern resource.

To examine that last statement more closely, consider the important UseCase for PermanentAnchors of when we fold a ShallowPage into another larger page. Here we cut and paste the text of ShallowPage into a section on the other host page, making the title of the ShallowPage a PermanentAnchor on the host page. Since good URLs are permanent, the same URL for the ShallowPage should direct the browser to the PermanentAnchor the text now falls under. i.e. mb.pl?MyPage and mb.pl?MyAnchor Thus, the PermanentAnchors should exist in the same namespace as the rest of the PageDatabase, and the URL schema is equivalent.

When the script is fed the URL mb.pl?MyAnchor, of course it isn't the case that it should load the page MyAnchor, since it doesn't exist. Rather, it should redirect the browser to mb.pl?MyPage#MyAnchor. However, we face a difficulty in that some browsers do not take the anchor in consideration during the redirection, even though RFC 2616, section 10.3.3 "302 Found", indicates that redirection using anchors should work all the time. The client should just do another GET on the URI given in the Location field. Anything else is a bug in the client.

One ugly solution to that is during syntax translation, we could theoretically have the script links to the actual URL when it encounters PermanentAnchors. That is, when it sees a LinkPattern, it first checks whether or not it is a PermanentAnchor. If not, it might emit mb.pl?LinkPattern; if it is, it would emit mb.pl?MyPage#LinkPattern. This hack is ugly since it breaks the idea that PermanentAnchors are addresses in and of themselves, and therefore permanent. For instance, SpiderBot?s should record the intended permanent URL, not where we are currently storing the information.

A solution?

A workaround could be to use mb.pl?anchor=SunirGoesToAmsterdam#SunirGoesToAmsterdam. Adding a link to itself to the permanent anchor is maybe a good idea in this case as the url is a little tricky.

Why can't you just use mb.pl?SunirGoesToAmsterdam#SunirGoesToAmsterdam. That would allow linking to permanent anchors as easily as to a full page: just smash words together.

Well, as the ExternalReferral? I'm going to just link to MeatBall:MyAnchor, not MeatBall:MyAnchor#MyAnchor. Consider the ShallowPage use case: MeatBall:MyShallowPage should still work post reworking. -- SunirShah

Managing Permanent Anchors

The trouble of course is doing this efficiently. In the worst case, the script could search the entire page database for the anchor. However, this is inefficient. A better answer is to translate each page when saved to extract all the PermanentAnchors on that page. Then, simply create a small PermanentAnchor database that holds merely the name of the host page for each anchor. That way, when looking up a permanent anchor, the script need only look in the anchor database for that entry, pull the host page name, and load it, an O(1) operation.

Another problem is that PermanentAnchors are not guaranteed to be unique. Some options are available here. One option is to simply prevent duplications, such as displaying an EditConflict dialog when attempting to create a PermanentAnchor already in use. Alternatively, a simple warning message could be shown, although that has the potential for being missed or ignored. Perhaps the most HumaneInterface, the script could simply load the text of the previous host page, remove the anchor, and resave that page before saving the new position of the anchor. The change would be listed on RecentChanges, naturally. See section "Name Clashes" below for more.

Syntax and Rendering for Permanent Anchors Definitions

If #SomeAnchor is already used for pointing to permanent anchors, then another syntax is required to define them.

When the URL pointing to an anchor is complicated, the definition of the anchor can just link to itself. This would make it easy to copy the link location using a browser and use it elsewhere. In addition to that, the definition can be rendered using an icon with an interesting ALT text, or as a as a link with a special CSS class that can be used to tweak appearance. The text should indicate that this is a "Permanent Link" and the preferred way of linking to this particular piece of text.

OddMuse uses [::SomeAnchor] to define a permanent anchor. When rendered, this acts like an ordinary page title: It searches for backlinks.

Another proposed syntax uses text for a PageAlias. The following, written on MeatballMission would define the page alias MeatballTheMission:

    PageAlias MeatballTheMission?

Contrast with PurpleNumbers, where the anchors are created automatically.

Name Clashes

When duplicates arise, the link should replaced with a small warning message and a link to the other occurence of that permanent anchor. This would be a very HumaneInterface -- no error message, no interruption.

Experience

On the EmacsWiki, nobody uses permanent anchors. The only good use they were put to was a glossary on the ICT4 wiki, and anchors for all the options in the OddMuse manual. Why is this? The permanent anchors required you to solve future problems. Assume you have two topics A and B on page one. Now you move topic B to page two. If don't want to avoid lots of broken links to B, you might want to use permanent anchors for it. The problem is that you must have thought about creating a permanent anchor for B in the time between writing about B on page one, and the first link to page one referring to topic B only.

Permanent anchors may replace PageRedirects, however. Assume you moved the content of page A to page B. You can now edit page A and put a page redirect from A to B there. Using the new permanent anchors where anchors and pages are in one namespace, you can delete page A and create a permanent anchor called A on page B. See PageAlias for more.

See also NamedAnnotation for a proposed usage pattern.

Comments

Trying to make a better PageRedirect and trying to make better NamedAnchorsInWiki both lead to the same solution. Good FeatureKarma?