History for ComonNameSpaces

??changed:
-
  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):

     <pre>
       ZopeProjects/
         - ProjectProcess
         - FrontPage
         - CompletedProjects/
         - ReplicatedStorage/
           - FrontPage
           - ProcessNotes
     </pre>

     !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