[Zope] Wiki Parser? (Was RE: [Zope] ZWiki)

[Kent Polk]

On 21 Apr 2000 16:25:01 -0500, Patrick Phalen wrote:
[...]

>There is a common need among open source and open standards communities
>(including Zope) to evolve discussions from loose and unstructured to
>something finally more formalized and ordered (e.g., specifications,
>documentation, etc.). The difference with the Zope community is that
>we actually have tools which could be adapted to that purpose.
>
>Wikis provide one model for the loose first stage (Usenet and
>threaded mailing list archives provide another). In a way, they
>overlay a brainstorming model onto the network model. They permit
>fleeting thoughts to be "captured in a bottle." The problem is how
>then to migrate from the loose to the structured, once the discussion
>has run its course and it's time to organize the material and publish
>something formal (documentation, for example).
>
>Of course this can be accomplished by someone laboriously combing
>through the Wiki or the archive and hand-assembling something, but it
>would be nice to have tools or hooks to automate the process.

[...]

>representation. What Wikis do well is capturing freeform,
>brainstorming-style discussion. Thereafter, it would be beneficial to
>have different representations of the information they contain, perhaps
>including a tree or outline view. 

>Or maybe there is some other tool available which already addresses
>this. E.g., there is wonderful application program called "Inspiration"
>(Win/Mac) which allows a user to bring up a graphical view and add boxes
>containing concepts (text and/or images), and then freely interconnect
>the boxes arbitrarily with lines to form a "concept map." Then, one
>mouse click can turn that into a collapsible/expandable outline view.
>
>Bottom line: is there a way to parse a Wiki and generate an outline
>view?

I've been testing some of these concepts out at the research center
where I work. It's quite difficult to get people together to
brainstorm, and when we do, the time is mainly spent educating
people concerning pertinent issues that they didn't even know
existed.  IMO, the Squish-dots and wiki's don't work so well at
combining education and free-form discussions as the edu aspects
need more structure to them.  So the structure you mention which
is needed after the fact is also needed before the fact.

I wrote a piddly little ZDiscussion/Cataloged ZClass I called
ZAgonos ('Out of Z list' :^) to impose a searchable, heirarchical
interface on edu-discussion topics, such as tips, how-tos, design
issues, implementation plans, etc. ZAgons are folderish ZClasses
which have a topic structure and include a tree display of child
ZAgons (and certain other objects). Each Zagon shows only it's
tree, but there is a frame-based display similar to the Zope
management interface which lets you browse the entire 'list'. It's
trivial to drop text from a discussion into a new Zagon, etc. but
not automatic, and the Zdiscussions are not tightly woven enough
to really make them reasonable for interactive development.  The
tree-interface and catalog make it trivial to locate information
that is buried pretty deeply, and since the structre is uniform
and simple, it makes it easy to navigate, locate, and add information.

What I'd really like would be to have the ability to morph heirarchy
and form onto an object. The ZAgons force heirarchy onto the
information, but obviously that isn't the way it really needs to
be done.

A good example might be an Implementation Plan for Security Issues:

 One might start out with an Abstract titled "We Need Better Security
 in this Department". The abstract could be followed by a list of
 issues that concern the instigator. Following the list of issues
 would likely be a list of resources including links to man pages,
 external URLs, etc for more information related to the issues.

 A mechanism (zwiki, whatever) for allowing others to comment on
 the topic generates enough interest and questions that some or
 all of the list issues are wrapped into a tree structure. Say the
 SSH item generates a lot of heat as it will require more education
 of users (who would rather just let someone else take care of
 their security) and breaks into discussions regarding SSH1 vs SSH2
 and whether or not to implement a keyservers, etc., all requiring
 more links and documentation (hopefully in a structured fashion)
 to assist. 

 Ahh, but there's the larger issue of cleartext passwords and imap
 clients/servers which really ought to sit above SSH, so the tree
 is changed. More structured info about SSL and which IMAP clients
 behave themselves and which do not is added... Soon you have a
 lot of information which would be almost unmanageable without a
 heirarchy.

 As you navigate the tree, each branch or leaf can be structured
 as its parent, searches operate in context (only search child
 objects), and topics can be marked as links and cross-referenced
 (and anchored) in other locations automatically.

IMO, workgroup systems without some sort of heirarchy, contextual
searches, etc. just become unmanageable and cease to be useful VERY
quickly.

Ideas?