The familiar namespace systems are all strictly hierarchic (java class names, domain names, xml namespaces...), meaning every level cuts the parent space up in disjoint (non-overlapping) subspaces. Thus it is guaranteed that

1. every space and every element (e.g. wikipage) has just one parent space it lives in
2. there is a unique path from the root through the space hierarchy to any element, like "org.tikiwiki.TikiDevelopment.SpecificSubject"

One big thing why I love wikis is that they allow for non-strict structurization of data: For example, if you have a page that documents the Forum feature, you can link to it from a forum Overview AND from a Documentation Overview. If you organised your pages in folders (strict) you'd have to decide whether to put it into the "docs" folder or into the "Forum" Folder.

One way of introducing a non-strict system could be using Categories as Namespaces. Like this:

1. When linking to and from pages in the same category, you can refer to it by their short name. So to link to "TableOfContent", the application would look for a page with that short name that belongs to all of the categories the refering page belongs to, and then up the hierarchy (see below how problems could be avoided...)
2. Categories are a non-strict hierarchy. You can e.g. make the category "ForumDocumentation" have the parent category "Forum" as well as the parent category "Documentation". Thus all pages in "ForumDocumentation" belong to these parent categories as well.
3. When creating a new page, the application looks for pages that link to it (normally one: the one where you wrote the name of the new page, rendered with a question mark). The new page inherits the intersection of the referring pages' categories by default. (which can manually be overwritten). Thus a category behaves like a whole wiki instance while you stay inside that category.
4. In any doubt, you can always give the page a full name, which is any path to it from root: e.g. org.tikiwiki.Documentation.ForumDocumentation.TableOfContent. From within the same wiki instance you could shorten to Documentation.ForumDocumentation.TableOfContent.
5. In the current wiki implementation, you can't create a page that already exists. This would have to be replaced by the following procedure:
   1. Making Links ambiguous is not allowed: Suppose you want to create "TableOfContent" in category "Documentation". Suppose there is TableOfContent in category "Forum" and a page that links to it. That page belongs to "Forum" as well as "Documentation". Then for the TableOfContent in "Documentation", you'd have to use the long name.
   2. Setting ambiguous links is not allowed: Suppose there is a TableOfContent in both categories "Forum" and "Documentation", but no page belonging to both categories (which is allowed). When you now try to set a link to "TableOfContent" from a page that belongs to both "Forum" and "Documentation", you are forced to use the long name, or at least sth like "Forum.TableOfContent".
6. Strict hierarchies still possible:
   In the case that your categories are disjoint at each level, this solution would just automatically be the familiar system of a strict hierarchy. But it would allow for more freedom if you need it.
7. Linking to categories is just one way:
   If you don't want namespace-hierarchies to mess up the normal category system, you could use a category/namespace system of its own.

for one level namespaces

I think that the main thing we should bear in mind is the usability. It is true that there hierarchic namespaces are widely used, but only in enviroments which use them as main organizational structure. Wiki is by its nature very different, so very deep namespace structure does not fit to it, and would make it too complex, without real benefits.

In some special cases, howewer, there is a need for namespaces (some examples already mentioned above, I would add very nice SpecialPage namespace from wikimedia), but 90% of these needs can be easily addressed by one level namespaces. And with some imagination we can solve the rest as well. I would strongly suggest to look at wikimedia namespaces as well as xml namespaces, which are both one level only and work perfectly. — gorn

Am Mittwoch, 9. Juli 2003 21:14 schrieb Chris Holman:
> I've been using wiki structures to develop manuals and help documents, but
> keep running up against problems with wiki's global namespace e.g. I would
> like to have an Introduction page, but this would conflict with other wiki
> structures using the same naming convention. I'm currently prepending each
> structure page with a short identifier which is less than ideal. This
> would be a key issue for the wiki structure to PDF conversion i.e. the
> Tikiwiki Manual.
>
> Thinking out loud:
> Is there any way to create separate namespaces for each structure?
> Is this the same thing as creating a separate wiki?
> If tikiwiki could support multiple wikis, including dynamic creation and
> deletion, then each structure could be its own wiki.
> What repercussions would this have?
> Is the ACL system up to the job?
> etc, etc...
>
> Perhaps there is an easy solution staring me in the face?
>
>
> Regards,
> Chris