Subject: Re: mechanised documentation and my business model solution
From: "Stephen J. Turnbull" <>
Date: Mon, 03 Apr 2006 23:42:56 +0900

>>>>> "A" == A Pagaltzis <> writes:

    A> * Stephen J. Turnbull <> [2006-03-25
    A> 16:55]:

    >> 1) The wiki information itself is versioned per page, and can't
    >> be tagged for easy rollback across pages.

    >> 2) Wikis don't support branching and conditional generation of
    >> documents (so that you can have a documentation "view" for the
    >> "bleeding edge", one for the "stable line", and WIBNI you could
    >> *diff* those two?)

    A> Both of these seem to me like simple matters of building the
    A> infrastructure to support them. These things are supported by
    A> any self-respecting version control system; why would it not be
    A> possible to implement them in a wiki? This seems like criticism
    A> of existing wiki engines, not of the wiki concept.

Of course; it's very hard to criticize a concept that is specified by
reference to a set of implementations.

But let me indicate the conceptual problems I see.

(1) Wikis are inherently page-oriented.[1]  When you hit the edit button,
    you get a text widget, *not* a checkout of the whole wiki.  This
    is *not* going to change; wikis are for easy update of individual
    pages.  OK, you could change it, but it would be an abominable waste
    of bandwidth, because absent external discipline people are going
    to scribble on one page at a time.

    But isn't lack of external discipline the very defining
    charactistic of the WikiWikiWeb?  True, the *goal* is removing
    unneeded impediments to authors, but the WikiWikiWeb achieves this
    goal radically---by removing *all* discipline.

(2) Why bother adding branching and conditional generation if you
    haven't a solution to the problem in (1)?  All you get is multiple
    tagged, branched incoherent versions of a basically incoherent

Really, given the variety of disciplines that various people have
described in this thread along, a much more appropriate way to
describe what we need is "Zope/CMF" or "Plone".  (Excuse my Pythonic
bias, those are the workflow systems I'm familiar with.)

[1]  This, and all other categorical statements, should be considered
to be completely covered in IMHO, YMMV, and similar acronyms.

Graduate School of Systems and Information Engineering   University of Tsukuba        Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
        Economics of Information Communication and Computation Systems
          Experimental Economics, Microeconomic Theory, Game Theory