History for ReducingImpedence

??changed:
-
I'm collecting notes here.

(See 
"the WikiNG proposal":http://dev.zope.org/Wikis/DevSite/Proposals/WikiNG for related stuff.)

On 19 Mar 2001, Kent Polk wrote::

 > How much thought has been given to the possibility of implementing
 > an automated hyperlinking facility (WikiNames :^O ) to CMF object
 > collections???

I've given this some thought.  I *really* want low-impedence link
authoring, and also want the document-namespaces of conventional wiki
*and* lineage (where documents are created from, and thereby offspring
of, other documents) that zope.org ZWiki have innovated.

For StructuredText-style documents, i want to maintain a shortcut for
referring to documents within the same collection by their name, but with
a slight bit more explicit effort on the part of the writer to distingush
such references.  I'm calling these things "CommonNames".  They 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 can apply a bit of discretion and map, eg,
   plurals to singulars - ![CommonNames] would map to ![CommonName] if
   CommonName already exists as a page.

   (If no variant exists, the plural will be offered as the name for the
   new document - but the creation actions for CommonName-style documents will
   offer editing of the name being used, so the creator can normalize to the 
   singular, or whatever variant they prefer.)

One other aspect to this question is realization of "link objects" in
zope.  These link objects would know how to render themselves (or
something would know how to render them) into many formats - XML, HTML,
StructuredText, Word, whatever manifestations the documents could have.  
Further, they would be able to play nicely with Interlinking Info
OrganizationObjects, for, eg, indirection that could track forwarding of
document locations as they are renamed and moved around the site.  ::

 > I mention this because almost every project possibility that I bump
 > up against has almost the same set of requested 'requirements'.
 > The good news is that I think we are gradually bumping off those
 > requirement items with the new core components of Zope/CMF, leaving
 > less for a developer to create. Some of the things that are left
 > are automated tree-views of document heirarchies arranged according
 > to query constraints (meta-data again...) and automated hyperlinking.

I think there will be some important common hierarchies, in addition
to the folder hierarchy - lineage, keyword hierarchies (i need to get
my notes concerning these online - my machine just had a disk crash, i
hope they're still there!), and others.