SourceForge.net Logo
June 2, 2006
GPL
ProWikiCenter
Cdml Philosophy

When ProWiki development started in early 2001, there was an immediate need to increase wiki layout abilities. There was no standard and there was a need for an extension strategy. Therefore we came up with CDML (Content Description Markup Language). The reasoning and philosophy behind CDML stands unchanged even now, in 2006.

Needs

  • there are constant user needs for powerful extensions (see CdmlTable or CdmlTeX)
  • in principle we want to support extensions to have additional key selling points
  • the market and marketing wants WYSIWYG

Strategy

Strategic decisions

  • we build CDML as a unifying extension system
    • we make part of it available through markup extension (see "two-world strategy")
    • and adapt to de-facto standards of wiki markup
  • we do not actively invest in WYSIWYG research
    • we will clone WYSIWYG it as soon as possible when good implementations become available
    • WYSIWYG can only be a partial anyway because extensions have moved far beyond font style and list indentation

Two-worlds Strategy

The world of markup
we explore but do not push our suggestions, we follow the wiki main stream with respect to markups
The world of extensions
CDML is used to efficiently implement whatever extensions are needed. There is not limit to these extensions.


Smileys as an example for the two-worlds strategy:

UseSmileys is an option to turn on support for smileys. It is an option because (1) not everyone wants smileys and (2) searching for smiley patterns costs a little performance. The feature DisplaySmileys needs to search for a number of patterns to replace them by icons. This is nice but it has costs and is not extensible to dozens or hundreds of images because the cost searching for all these special character combinations increases incrementally. These are costs that you have on any page, even if you don't actually use smileys. On the other hand our CdmlSymbol: it supports the same symbols (the syntax is a burden, so we offer both ways) but CdmlSymbol does not create costs when not used and can be configured for an arbitrary number of symbols without changing this situation.

Note the ambivalence to other wiki engines PluginStrategy: the user can choose and assemble a wiki according to his needs but each Plugin creates a little additional burden. In the end the user finds that his system has become clumsy and slow ... by following his own freedom of choice and responsibility.

ProWiki is different: we want full-blown systems that offer all features in a consistent low-cost way. The community should be able to have them or turn them on/off depending on their functional needs, not because they dislike the work of installing a plugin or because they dislike the performance penalty of the plugin.

Performance & Efficiency

There is a penalty on supporting 100 markups because this means a hundred character patterns to search for.

There is no penalty on supporting a hundred CDML extensions because there is only one recognition pass through the wiki text (basically looking for "[[") that recognizes all CdmlElements.

Reasoning behind the strategy

Related facts:

  • HTML
    • HTML is not useful in wiki authoring (although it is useful, even unavoidable, for displaying pages)
    • HTML is too complicated to put it in the hand of users, it also would create a two-class society
    • HTML is far to inconsistent and powerless to implement powerful functions
  • WikiMarkup
    • is not useful for having many extensions
    • many markup extensions would cost performance for regular expression search
    • adding extensions makes markup it complicated and idiosyncratic
  • WYSIWYG is a problem
    • competing browsers don't (won't) offer the necessary compatible UI extensions
    • implementation is too expensive
  • Standards
    • there are no real markup standards, but de-facto standards
    • extensions will always be ahead of standards
  • XML (became popular at a later date)
    • is not better than HTML with respect to user interaction

FolderProWiki FolderPhilosophy FolderCdml