Here are some Thoughts about the features "AREAS" and "PERSPECTIVES" as well as about the planned "NAMESPACES"

Areas

• is a feature to limit the visibility of any categorised content based on a set of categories and related perspectives.
  Actually this feature "binds" a category and its content to a certain category. The so called "category jail" is used for this.
• All content which is categorised with one category of this specific set of categories will be visible just and only the allocated perspective.
• "AreaS" is an extention of "Perspectives"

Perspectives

• is a feature, that allows to override preferences. A perspective can be used to show the same content in different design or different structure, with different modules.
• "Perspectives" can be used to make up a personal desktop to see the default content of a website with individual modules and menus.
• "Perspectives" can be used to set up certain Spaces for workgroups.
• Combined with "Areas", "Perspectives" can be used to setup different individual public websites (or intranet-workgroups), where the links to categorised content always will be directed to the appropriate perspective.

Workspaces

• are a certain combination of "Categories" and "Perspectives", whilst the categories in the so called "Category Jail" are just limiting search results.
• in opposit to "Areas" the visibility of any content is not limited to a "Workspace/Perspective".
• Thus any content can be viewed in any Workspace once a link is known and the user has the appropriate permission.
  Since we have "Areas" to limit visibility to certain "Perspectives", this behaviour of "Workspaces is a feature (and not a missing development or bug).

What is the problem?

• As Marc Laporte stated at dev.tiki.org/NameSpaces, it is not possible to use the same page name for a wikipage twice or several times.
• This would lead to the problem, that a workgroup could not use the simple common names "timesheet" or "eventplanning" etc. for a wikipage, if this name was "taken" by another workgroup before. This obviously would lead to a massive confusion after a while.
  Just see the different used prefixes for translated pages on doc.tiki.org, if they have the same spelling in different languages.

What can or should Namespaces do?

• "Namespaces" would be a feature, that automatically adds a prefix or a suffix to a page (or to any content) when it is created.
  This prefix (or suffix) would be faded out whilst the user "is in the Perspective".
• Being in another "Perspective" a link without prefix would either not work (not found error) or lead to another page with the same name, if one would exist in this "Perspective".
• From "outside" the "Namespace" related "Perspective" ... meaning from the "default website" or from another "Perspective" a link need to be extended by the "Namespace related prefix (or suffix)" to be directed to an appropriate page.

How that could work

• I suggest to extend the "Perspectives" feature with one or a few database table(s) and kind of a parsing script, that strips and extends the prefix/suffix of the actual "Perspective/Namespace" aswell on content-creation as on content-lookup.
• The lookup of this/these database table(s) must be limited to some conditions, not to extend the loading times of all content of a webssite/intranet
  • Thus no lookup when default perspective and no prefix/suffix
  • Only lookup to check if a content is existing in the active "Namespace/Perspective", if no prefix/suffix
  • A given link with prefix/suffix needs no lookup, but just directing and stripping

I hope I could explain my thoughts understandable.

In my mind, "Namespaces" will make the "Workspaces" real "Workspaces".
The issue with the absence of "Namespaces" and the related problem of a lack of necessary naming flexibility seems to have been discussed frequently.
It was made clear to me first time by 'amette' at the TikiFestBLN2011.

Torsten