NameSpaceWeb

Definition:

A NameSpaceWeb is a TWiki-style "Web" that defines a topic namespace. SubWebs are associated with a NameSpaceWeb using simple controls. Any topic names that are defined in any SubWeb in the NameSpaceWeb must be unique. The controls for exporting topic names to other SubWebs are as follows:

• exporting topic names to all other SubWebs in the current NameSpaceWeb
• exporting topic names to all other webs in the site.

See: NamespaceControl

-- RaymondLutz - 31 Dec 2003

This appears to be proposing set union of webs, with uniqueness of topic guaranteed by non-overlapping subsets.

One issue with this is that webs currently form a namespace - that is a set of names (with associated information). Performing a union of sets with overlapping keys (topic names) but not values (topic contents/structure) results in a bag.

As a result a SubWeb is a restricted form of web - according to the definition above. Subwebs have existed for a long time however in other forms as distinct namespaces associated with a single key/topic in a parent namespace.

I'd like to see a union of webs - with FindElsewherePlugin a good initial first step.

For those confused:

• Define a NameSpaceWeb: "Wiki" (Peter, I'm choosing this since TWiki has been taken here...)
• Define 3 physical webs:
  • Codev
  • Support
  • TWiki
• Make "Wiki" the union of Codev, Support, TWiki

There wouldn't be allowed any overlapping names (or else the namespace set becomes a namespace bag). Support, Codev & TWiki would be bad for this as things currently stand.

Issues: (good/bad?)

• Subsetting is akin to inheritance, and therefore hits all the same issues.
  • Does this system hit multiple inheritance issues? Specifically diamond inheritance?
    • No, each SubWeb can only be associated with one and only one NameSpaceWeb, or ALL
    • Yes - the ALL means that you always hit problems. This doesn't cause diamond inheritance, but does effectively create global "variables". Would this be a problem? Only usage and practice can answer that. The problems they cause for maintenance issues in software is well known. The concept of a global topics is an interesting one however - and conceptually useful in terms of a glossary & users web. (However FindElsewherePlugin handles that pretty well TBH at present)
• Complexity (user):
  • Requires access to WebPreferences & ability to setup webs to create custom views.
    • Allows code optimisations.
    • Limits usefulness to site administrators.
  • Requires namespaces to be handled at site creation time, or you're left with some fairly non-deterministic behaviour from a user point of view. (Some topics will automatically link to the alternate web, some won't - in practice, you want both . This problem, is shared with the FindElsewherePlugin)
    • Are SubWebs always distinct non-overlapping sets?
      • How is this ensured? (compare with wiki:SisterSites)
• Static
  • cf the search & slice approach in LogicallyNestedWebs
• Proliferation of webs ?
  • If SubWebs could be included in multiple NameSpaceWebs (as indicated in NamespaceControl), then this potentially encourages large numbers of webs. (Not a problem perhaps if "web" is set as a WebForm value as well - since this becomes akin to TopicClassification. One problem however is the need to keep the preferences & webforms of these subwebs in keeping with each other)

The questions this also raises are:

• What benefits does this provide over a simple TWikiWeb which pulls in links from other webs using FindElsewherePlugin ?
  • This also allows TWiki Webs to be treated as SubWebs in a way very similar to the one you describe.

• How would (does) this interact with MegaTWiki features ? (Given its the only listed release focus is MegaTWiki features)
  • Given this already implements SubWebs and people appear to be happy with it.

• How close is the assessment to what you envisioned ?