For Tiki10: adding native support for namespaces.
- We need it for the Business Plans project.
- Say I want a Glossary Farm as a SaaS offering, like a WikiFarm
- Users create an account in the system and can join one or many glossaries
- Would help for Areas Perspective Multi-domain dogfood
We want this for group names and wiki page names (at least!) but perhaps trackers and forums.
We would like pref override per namespace (like we have for perspectives). So we can override site title, logo, domain name, etc.
There needs to be a manager group per namespace. Manager decides of categories and permissions in the namespace. And also of group membership with Group Transitions
The primary purpose of a namespace is disambiguation in page names, allowing for common page names to be used in multiple projects or workspaces. Other features may be attached to them, but this may complexify implementation.
Tiki already has some ways to deal with namespaces in some limited ways. Users often use prefixes or sufixes. There is even a feature to hide the suffix after a certain identifier.
A complete implementation would need to take these hacks a step further.
- Displaying the page name must be reduced to the base name, potentially displaying the namespace as a secondary attribute or tooltip.
- Links within a wiki page must first lookup pages within the same namespace.
- Page creation from a link must create a page in the same namespace by default.
- The Create/Edit page module must also consider the current page’s namespace.
- Search functionalities would also need to be adjusted, but the cases need to be analysed with more details.
The use of namespaces for non-wiki features may simply be cosmetic as unicity is rarely a constraint.
Namespaces are closely related to category hierarchies. The primary difference is that there can be a single namespace for a wiki page while there can be multiple categories. Given a matching category structure with the namespace structure, automatic assignment of the category would simplify permission management.
Perspectives are a central part of workspaces. A preference could be created to specify the default namespace. The automatic categories provided by the category jail would no longer be required for wiki pages.
For consistency, the concept of primary category could be introduced to all features, allowing automatic permission assignment to work in a predictable manner. A primary category would allow to simplify the idea of looking up a perspective based on the object, which was not reliable due to the multiple possible categories.
- “There needs to be a manager group per namespace”. Why is this a requirement? If the system policy is to have many small namespaces, e.g. 1 namespace per student workgroup in a class, this requirement will lead to an excessive amount of manager groups.
- Should namespaces be freely defined by the user? E.g. naming a page: myspace:thepage creates the namespace “myspace” if it doesn’t exist, or should the use of namespaces by confined to a defined set. Thus the creation of myspace:thepage would fail, unless a namespace “myspace” is already explicitly defined. Having attached elements, e.g. a dedicated Manager group implies only predefined namespaces can be used
- Namespaces (and wiki page names) should not include leading and trailing whitespace. The entered page name “a:page” is the same name as ” a : page “.