ComonNameSpaces

Here are raw notes that will be made into a proposal. The underlying idea is that of a CommonNameSpace, along the lines of a wiki namespace. Distinctions are:

Being a general framework, for any content authored using StructuredText or HTML (and others, as we implement them), not just for a particular content type.
CommonName link cues are more explicit, to avoid linking surprises and clutter that bother many wiki users.
Intrinsic attention to scaling, with eye to collections of namespaces across a site (and eventually, further).

CommonNameSpaces provide for two kinds of organization - a locality of reference, within a site, and hierarchical "lineage" organization within the namespace.

The first provides for low-impedence cross-references within the namespace (and across namespaces), while the second provides for fine-grained refinements of the site organization that typical folder/directory-based models provide. The implementation in StructuredText has refinements to wiki names that should satisfy objections over unintended links, while retaining wiki's low-impedence operation and raw-text readability features.

There are many ways that site content can be connected. A CommonNameSpace is a fundamental one, delineated as a collection of pages that hold eachother as immediate neighbors. "Immediate neighbor" means that they can link to each other using unqualified CommonName shortcuts.

"CommonNames" would have similar capitalization rules as WikiForNow (like typical wiki, but allows numbers and "~" tildes), but:

CommonNames would have to be enclosed in square brackets to be recognized - "[CommonName]". No unintended WikiLinks popping up in your text left and right.
Stuff that doesn't qualify as a CommonName does not turn into a link if it's enclosed in a square bracket so that you can use square brackets as you normally would for non-CommonName text, [without surprises].
To turn arbitrary text into links with a shortcut gesture, you have to double the square brackets: [[this would be a link]] to a horribly named document.
As a bonus, since the mechanism for recognizing CommonNames in square brackets is so definite, we allow definition of policies, like mapping plurals to singulars - '[CommonNames] would map to [CommonName]' if CommonName already exists as a page, and the page author specified CommonNames as a plural.

A common name space is the collection of objects that share an immediacy of reference to one another - the pages in the space can all make unqualified [CommonName] references to eachother.

This definition has a few implications:

By transitivity, any page can immediately be in only one CommonNameSpace.

To understand this, it helps to realize that it isn't useful to have a page in two, disjoint namespaces. Otherwise, the common names on the page will have different meanings in the different namespaces - some may be undefined in one name space, others undefined in the other.

CommonNameSpaces can contain other common name spaces. Thanks to acquisition, pages in the contained space can use unqualified references to denote pages in the container (and it's container, etc). Pages in the container do not have the same privilege - to refer to pages in a contained space, they must use a relative path, prefacing the name of the interior space's folder and then the page. So (with folder names having an appended /, pages not):
```
       ZopeProjects/
         - ProjectProcess
         - FrontPage
         - CompletedProjects/
         - ReplicatedStorage/
           - FrontPage
           - ProcessNotes
     
```
ZopeProjects/ReplicatedStorage?/ProcessNotes? can refer to ZopeProjects?/ProjectProcess? as [ProjectProcess]. The ProjectProcess page cannot, in turn, make direct reference back - it has to spell out [ReplicatedStorage/ProcessNotes].

On a moments thought, this makes sense. There could be another project (eg, ZopePageTemplates) which has its own ProcessNotes. Then, which is meant by a non-qualified [ProcessNotes] from the top level - ReplicatedStorage/ProcessNotes? or ZopePageTemplates/ProcessNotes?? Answer: neither. Going upwards in the folder hierarchy does not present this branching prospect, only going downward does.

Organizational Management of a CommonNameSpace

"Gathering" a subspace from a collection of pages in a space: An operation is provided for pushing a collection of pages within a space into a sub-space. That collection can be identified by identifying a page to be gathered with all its offspring, or by using other criteria (maybe a tool for graphically showing and selecting within page "affinities" - collections of pages which refer to eachother more than other pages do).
Existing references from remaining pages to pages gathered into the new subcollection are automatically revised to track the change. (We may be able to design the framework for link objects (see ReducingImpedence for scant description) to intrinsically track this, don't know whether or not that's the right direction to go.)

There would be an inverse operation, called something like "marging".

LinkObjects