[linux-l] Formatierung durch CAS (was: WikiDok: Trennung von Inhalt und Form)

Sa Okt 22 23:47:42 CEST 2005

On Thu, Oct 20, 2005 at 07:03:04PM +0200, Mike Dornberger wrote:
> > Dass es auch anders geht, zeigen Mathematik-Programme wie z.B.
> > Mathematica. Dort schreibt man die Formel einfach hin wie im
> > letzten Beispiel, und er schaut selbst, wie sie am besten aussieht.

[...]

> Das CAS (Computer Algebra System) denkt, die Formel sollte soundso
> dargestellt werden. Oftmals ist es aber sehr wünschenswert, daß gewisse
> Dinge anders dargestellt werden. Sagen wir "aus didaktischen Gründen".

Okay, dann habe ich mich wohl falsch ausgedrückt: Ich wollte nicht
sagen, dass Mathematica bereits das Nonplusultra ist, sondern nur
ein Beispiel für einen anderen Ansatz geben.

Meinetwegen können in Formeln ja ruhig Elemente zur Gruppierung
und zur Hervorhebung drin sein, also (mal Schemenhaft):

	c*{a/b}

Wobei die geschweifen Klammern bedeuten sollen, dass dieses Konstrukt
einzeln steht (d.h. dass das "c" nicht mit auf den Bruchstrich darf).
Bzw. dafür würden eigentlich auch normale Klammern reichen.

Oder Hervorhebung:

	c*\emph{a/b}

Ich sage nicht, dass es wenig Aufwandt wäre, aber es *muss* doch was
besseres geben, als die Formel Symbol für Symbol aufbauen zu müssen.
Will ich z.B. dass die Klammern ausreichend groß werden, dann muss
ich in LaTeX immer \left( ... \right) schreiben. Bloß für ein Klammern-
paar! Und bei komplexeren Formeln (wenn man sich keine Makros
definiert) bleibt die Semantik u.U. komplett auf der Strecke. Es
kann doch nicht sein, dass man z.B. ein halboffenes Intervall per
[a,b[ angeben muss ... bzw. dass man sich überhaupt damit rum-
schlagen muss, ob es nun [a,b[ oder [a,b) geschrieben wird.

Der Ist-Zustand, dass sich viele Mathematiker mehr mit LaTeX als
mit dem Dokument selbst beschäftigen, ist jedenfalls mehr als
unbefriedigend, und die AMS-Pakete helfen zwar viel, lösen aber
einige grundlegende Probleme immer noch nicht.

> Ergo: Ich kann maple nicht in einer "make"-Kette verwenden, da es die
> Formeln nicht so ausgibt, wie ich es brauche. (Mal ganz zu schweigen von dem
> schlechten Export nach LaTeX-Code.)

Ja, das ist korrekt. Leider :-(

> Ich denke mal, die Wikipedianer haben/hatte da ähnliche Probleme wie ich mit
> maple. Siehe z. B. die Einträge für chemische Elemente. Die haben alle das
> Periodensystem der Elemente mit dastehen, wobei das jeweilige Element
> farblich hervorgehoben ist.
> 
> Sicherlich wäre es am sinnvollsten, sowas wie eine Funktion zu bauen, der
> man den Elementnamen übergibt und die dann die Tabelle so aufbaut, wie sie
> sein muß, aber müßte man dann nicht extra das MediaWiki umschreiben? Dann
> kommt der nächste Anwendungsfall für ein anderes Tabellenlayout...

Das mit den chemischen Elementen ist ein guter Einwandt.

Analog ist das übrigens auch mit der Zeitgeraden, die bei den
geschichtlichen Kapiteln immer mit dabei ist.

Obwohl MediaWiki bereits ein kleines Template-System (d.h. parametrisierte
Wikiseiten) hat, konnten solche Sachen damit noch nicht gebaut werden. Man
könnte deren Template-System weiter ausbauen, aber ich denke, es wäre
sinnvoller, das zu nehmen was man schon hat: Funktionen in PHP, sonst ist
ja wieder die Gefahr des "NIH", ganz zu schweifen von Sicherheitslücken
und der unnätigen Komplexität, die eine Wiki-interne Programmiersprache
mit sich bringen könnte.

Allerdings sehe ich nicht so wirklich das Problem darin, "das MediaWiki"
zu diesem Zweck "umzuschreiben". Ein System von "programmierbaren
Templates" reicht doch aus. Zum Beispiel könnte es ein Verzeichnis
geben, wo man einfach "Templates" definieren kann, d.h. PHP-Funktionen,
die entsprechende Parameter nehmen, und Wiki-Code ausspucken. Das wäre
für jede, der mit seinem eigenen MediaWiki spielt, leicht anzupassen, und
man kann es ja als Vorschlag dem MediaWiki- bzw. Wikipedia-Projekt geben,
sodass entsprechende Leute das einpflegen.

Wikidok & Templates:
--------------------

Auf Ebene des WikiDok-Projektes jedoch wäre noch ein anderer Ansatz
denkbar: dass man nämlich einfach ein Element hat, welches erlaubt,
die Ausgabe eines externen Programmes mit ins Dokument einzufügen.
Natürlich nur Programme innerhalb eines vordefinierten Include-
Pfades. Dann gäbe es z.B. ein Programm ".../wikidok/templates/ptable",
welches über <include-prog name="ptable" param="Br"> eine Perioden-
Tabelle für Brom erzeugt und einbinden lässt.

Einfache (nicht-includepfad-beschränkte) Templates könnten dann entweder
statische Seiten sein (ist das jemals sinnvoll?), oder in XSLT
geschriebene (weil XSLT gewisse Berechnungen zulässt, Parameter
entgegen nehmen kann, aber keine Sicherheitslücke darstellt, wenn
man <xsl:document>-Elemente verbietet bzw. ignorieren lässt).

Wie auch immer, vielen dank für den Hinweis. Templates habe ich in
Wikidok noch nicht bedacht, aber es wäre mehr als cool, wenn sich
auch diese einfach als Teil des Filtersystems verstehen ließen, sodass
das Wikidok-XML-Format nicht um Template-Fähigkeiten erweitert werden
muss, sondern nur um entsprechende Include-Befehle.

Weitere Anregungen sind sehr willkommen.

Stilistische Anpassungen:
-------------------------

Unabhängig davon, wieviel die Wiki-Sprache nun kann und nicht kann,
bin ich dennoch dafür, dass man nachträglich kleine stilistische
Aufbesserungen vornehmen kann. Deshalb bin ich immer dafür, über
LaTeX, XSL:FO, Lout, etc. zu gehen: Damit ein Typsetzer (oder ein
perfektionistischer Autor ;-)) nochmal die Endfassung aufpolieren
kann. Beispielsweise durch Einfügen geeigneter Seitenumbrüche,
kleinen Korrekturen an Formeln, etc.

All dies hat natürlich erst in der "Endfassung" zu geschehen, und
es macht keinen Sinn, diese Dinge in die Wikisprache mit hinein
zu quetschen, weil sie ihren Sinn verlieren, sobald am Wiki-Code
weitergearbeitet wird. (z.B. würden manuelle Seiten- oder Zeilen-
umbrüche ihren Sinn verfehlen und grauenhaft aussehen, wenn sich
der Absatz nach unten verschiebt)

Es mag zwar zunächst "bequem" erscheinen, diese typographischen
Aktionen als Vorwandt zu nehmen, stilistische Mittel oder gar
LaTeX-Code mittem im Wiki-Dokument zu erlauben, aber das Gegenteil
ist der Fall: Diese Konstruktion wäre sehr fragil. Zum einen müsste
dann Code für jedes potentielle Ziel gegeben werden (also LaTeX,
XHTML, Lout, XSL:FO, DocBook, ...). Und zum anderen können diese
Zusätze sehr schädlich sein, wenn entweder am Dokument weitergearbeitet
wird, oder wenn der Stylesheet verbessert wird.

Hingegen im Ausgabedokument (damit meine ich z.B. die LaTeX-Datei)
stehen das Wiki-Dokument und die Ausgabesprache bereits fest. (per
Definition ;-)), daher passt diese Art von Änderungen am besten
dorthin.

Insbesondere sollten die Autoren sich während der Arbeit am Wiki
(also während des Schreiben/Ändern des Dokuments) sich nicht auf
solchen Mist konzentrieren.

> Aber vielleicht wird das ja auch zwischenzeitlich gemacht (MediaWiki
> umschreiben meine ich). Ich denke mal, es ist nicht so einfach, mal eben
> alle Server auf die neue Software umzustellen. Ich glaube mich zu erinnern,
> daß bei so einer Umstellung auch schon mal Daten verlorengegangen sind.

Nö, also die Wikipedia hatte immer ne recht aktuelle MediaWiki-Version.
Meistens sogar ne neuere, als ich auf meinen internen Seiten habe. Die
Wikipedia-Seite ist IMHO eine gute Demo für das aktuelle MediaWiki.  ;-)

Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR