Vorteile:

• mehr Strukturierungsmöglichkeiten
• Offenheit für Erweiterungen

• Cdml ist nicht WikiLike, es gibt wieder eine Syntax zu lernen.
  
• Cdml trennt nicht die Formatierung vom Inhalt. Die Probleme, die bei Html mit CascadingStyleSheets gelöst wurden, werden so neu erfunden.

Hinter den CDML-Erweiterungen steckt der Wunsch, das Wiki tauglich für Schul- und Universitätsanwendungen zu machen. Dass auch einfache Erweiterungsanforderungen bisher in der gleichen Syntax gelöst wurden, war naheliegend.

Was für die oben genannten Anwendungen fehlt, sind die Möglichkeiten für:

• mathematische Formeln
• geometrische Zeichnungen
• Zusammenstellung, Durchführung und Auswertung von Tests
• ...

 [[Formel]
 x 1,2 = b/2 +- Wurzel(b^2/4 - c)   
 ]

 [[Geometrie]
 Punkt A (3 -1)
 Punkt B (1 2)
 Gerade g durch A B
 ]

Die Alternative, das als Graphiken zu erzeugen, hochzuladen und einzubinden ist zu zeit- und resourcenaufwendig und zu wartungintensiv. Hier hat das Wiki das Potential gängige Arbeitsweisen um einen Faktor 10-100 effektiver zu machen. --hl

Benötigt werden also Elemente, die nicht als WikiText gerendert werden, sondern durch einen anderen Prozessor. MoinMoin benutzt dazu #Prozessor. Damit könnte man dann auch Bewährtes wiederverwenden, wie z. B. TeX für Formeln. -- ToKa

Ob #Prozessor oder [[Prozessor] ... ] kann ja nicht ausschlaggebend sein. Die Frage ist, was dahinter passiert und wie die Einbindung erfolgt. Grundsätzlich sehe ich zwei Möglichkeiten, jeweils mit Vor- und Nachteilen.

Variante 1 (Resultate werden als Grafikfiles erzeugt und eingebunden):

• Vorteil: es wird kein Java benötigt
• Vorteil: vorhandene Tools können genutzt werden
• Nachteil: umfangreichere Interface-Problematik
• Nachteil: Belastung des Servers
• Nachteil: gecachte Grafiken brauchen viel mehr Platz
• Nachteil: in einem Toolreservoir wird es für den Benutzer keine Konsistenz geben, Benutzung komplex, großteils englisch.

• Nachteil: Java muss vorausgesetzt werden
• Nachteil: Aus praktischen Gründen sollten die Applets ca. 30 KB nicht überschreiten (diese Grenze wird in Zukunft nach oben wandern).
• Nachteil: Die Java-Applets müssen entwickelt werden
• Vorteil: Das Interface ist einfach und schon vorhanden
• Vorteil: Der Server wird nicht belastet
• Vorteil: Es werden keine zusätzlichen Resourcen benötigt.
• Vorteil: Die Erweiterungen können konsistent und deutsch sein.
• Vorteil: Potentiell die bessere Performance.
• (Ideeller Vorteil: Endlich einmal ein sinnvolles Anwendungsgebiet für Java Applets)

Ich würde aber gerne auch die Variante 1 realisieren, weil sie bestimmte Vorteile (wie z. B. TeX-Einbindung) zuläßt. Siehe auch WardsWiki:MathWiki.

Es sollte doch möglich sein, Variante 2 zu realisieren und die Ausgabe zu cachen. Dann könnte man die Seiten auch ohne Java anzeigen. --ToKa

Eine Grundfrage dabei scheint mir, wie die Gruppierung gelöst werden soll. Das es eine schließende Klammer geben soll "]" ist nicht WikiLike und auch nicht allgemein, denn es könne Renderer geben, bei denen "]" zur normalen Syntax gehört.

1. Solange die Klammer gematcht sind, ist das mit CDML verträglich.

2. Ich werde bei Bedarf eine Adaptierung der Syntax vornehmen, um Kollissionen zu vermeiden.

• Ein Weg könnte OptischeFormatierung wie in der SprachePython realisiert sein.

Wäre möglich, warum nicht.

• Ein anderer wäre, eine spezielle Formatierung jeweils für eine ganze Seite gelten zu lassen, und einen Mechanismus ins Wiki einzubauen, so daß man Seiten in anderen Seiten anzeigen kann. Das wäre auch sehr gut um die Seiten klein zu halten und in logische Fragmente zu unterteilen. So könnten auch Formeln wiederverwendet werden und Menschen leichter gleichzeitig an einem Projekt arbeiten. Dies erscheint mir persönlich als sehr interessanter Ansatz.

Das ist ein Gedanke, der vor allem im Bereich dessen, was wir als EzineFunktionen bezeichnen, zu Hause ist. Ein Nachricht entsteht, wird bearbeitet und läuft durch verschiedene Integrationssysteme (Newseite, Archiv). Das steckt bei uns noch in den Kinderschuhen.

• ObjektOrientierung könnte auch ein Weg sein. Teile einer Seite oder die Seite selbst können Eigenschaften haben und diese von anderen Objekten erben. Wenn ich zum Beispiel eine Umfrage machen möchte, so sollen lauter kleine Seiten entstehen, die einem Bestimmten Muster / Template folgen. Ich könnte nun eine MutterSeite erstellen, die die Strukur enthält und diese alse Ahn neuer Seiten eingeben. So könnten auch verschiedene Renderer mit geerbt werden. Auch zu dieser Lösung bedarf es einer möglichst allgemeinen Unterstrukturierung bzw Gruppierung einer Seite. Es müßte möglich sein, eine irgendwie geartete WikiSeite mit Unterelementen auf einen Text abzubilden und umgekehrt.

Die Funktionen selbst sind kein Problem. Die Herausforderung ist hier, das System trotzdem noch so einfach zu halten, dass Benutzer nicht überfordert werden. -- hl

Diskussion

...mehr Strukturierungsmöglichkeiten...

Es ist tatsächlich so, dass laufend Erweiterungen verlangt werden.

Man könnte sich auf den Standpunkt stellen, dass diese Erweiterungswünsche an sich den Geist des Wiki verletzen. Das wäre aber eine missionarische Einstellung, die die Verbreitung des Wiki behindert.

Meiner Meinung nach ist es notwendig, die Einsatzmöglichkeiten des Wiki durch Erweiterungen auszudehnen. Der zu bewahrende Geist des Wiki scheint mir in der Einfachheit und der raschen Änderbarkeit der Inhalte durch die Benutzer zu liegen.

...nicht WikiLike (passt CDML ins Wiki?)...]

Manche WikiEngine erweitert seine Syntax durch Wiki-ähnliche Elemente (mehrere Rufzeichen am Zeilenanfang=Überschrift, spezielle Syntax für Tabellen). Diese Erweiterungsmöglichkeiten sind zwar WikiLike, definieren aber keine Syntax und bleiben so Insellösungen für Einzelfälle.

Die Frage wäre, ob es eine Syntax mit mindestens gleich viel Ausdrucksmöglichkeiten gibt, die besser ins Wiki passt.

Zur Information: Bis jetzt hat kein Benutzer gesagt, dass er CDML zu kompliziert findet oder dass er damit nicht umgehen kann.

...Probleme HTML/CSC neu erfunden...

Dort, wo CDML sich in den grafischen bzw. dynamischen Bereich bewegt (siehe DseWiki:JavaAppletsImWiki, DseWiki:WikiQuizz), kann es überhaupt nicht mit HTML/CSC verglichen werden.

Dort, wo CDML in HTML umgesetzt wird (z. B. CdmlTabelle), ist es das Ziel eine brauchbare Gestaltung vorzugeben, die in den meisten Fällen parameterfrei verwendet wird.

Es scheint mir wichtig, dass sich CDML an ein anderes Publikum richtet: an den normalen Benutzer, der kein EDV-Experte ist: den Schüler, den Lehrer etc. HTML und CSC sind für dieses Publikum und im Rahmen des Wiki nicht handhabbar. --hl

Ja, das ist klar. Aber trotzdem sollte man versuchen so weit wie möglich Struktur und Formatierung zu trennen. Wenn mit Wiki größere Projekte realisiert werden sollen, die ein einheitliches Aussehen haben sollen, dann kommt man eh nicht umhin so etwas zu tun. --ToKa

Eine vollständige Trennung von Inhalt und Format setzt semantisches Mark-Up vorraus - so wie mit XML oder SGML. Das ist zu kompliziert fürs Wiki. Eine teilweise Trennung von Inhalt und Format ist jetzt bereits gegeben. Wer nicht alle Parameter der Elemente spezifiziert, verwendet die von der WikiEngine vorgegebenen Defaults, die für die ganze Site zentral und getrennt vom Inhalt festgelegt sind. -- HelmutEnckRadana

Ich halte CDML für eine sehr gute Sache, habe aber trotzdem was zu meckern: Wie kommt das Ding bloß zum Namen CDML? Es beschreibt doch gerade nicht den Inhalt, sondern seine Präsentation! -- her

Es hat im Dezember 2000 den Vorschlag gegeben, das so zu nennen; in der Folge gab es damals keine Einwände bzw. keine besseren Alternativ-Vorschläge. Content ist außerdem ein hinreichend vager Begriff unter dem man im Extremfall

• den semantischen Inhalt (was ist damit gemeint),
• den sprachlichen Inhalt (wie ist es gesagt),
• den physikalischen Inhalt (was ist tatsächlich gespeichert),
• wie wird es aufbereitet (als HTML-Code),
• wie soll es dargestellt werden (vom Browser unabhängig),
• wie wird es dargestellt (vom Browser abhängig),
• wie sieht es der Benutzer (optisch),
• wie versteht es der Benutzer (als Empfänger in der Kommunikation)

und vielleicht auch noch anderes verstehen kann. Praktisch vermischen sich allerdings verschiedene Ebenen im CDML.

Fragen

Frage:

Gibt es ein deutsches Wiki, was sich mit InterWiki Konzepten und der Weiterentwicklung von WikiWiki auseinandersetzt (vielleicht auch als Tunnel des MeatBallWiki?)

Antwort:

Wenn du meinst in Diskussion: meines Wissens noch nicht. Die deutsche Szene ist wohl noch zu jung. Wenn du meinst in der Sache: Wir beschäftigen uns technisch mit der Vernetzung verschiedener WikiWebs. Z. B. gibt es Funktionen, die dem Administrator die Arbeit erleichtern, indem sie ihm eine Zusammenschau seiner verschiedenen WikiWeb-Systeme (recent changes, logs etc.) ermöglichen. Für Benutzer wird es Suchmöglichkeiten über mehrere WikiWeb-Systeme geben. Vielleicht gibt es einmal automatische Links über Wiki-Grenzen hinweg. Ich denke dass Konzepte in diesem Bereich nur Sinn geben, wenn sie in Kontakt mit realen Bedürfnissen entstehen und sich im praktischen Einsatz bewähren. --hl

Frage:

Gibt es Vorschläge, wie mehrsprachige WikiSeiten aussehen könnten ? Wie kann man eine Seite in einer Sprache anlegen, und dann nach und nach Teile übersetzen, wobei Quelle und Übersetzung auf einer Seite verbleibt und je nach UserEinstellung präferentiell die passende Sprache angeboten wird ?

Antwort:

Ich habe darüber schon nachgedacht, aber noch nichts implementiert. Siehe CdmlGedankenZuMehrsprachig.