[linux-l] WikiDok: Trennung von Inhalt und Form (was: Dateisystem als Datenbank)

[Volker Grabsch]

On Fri, Oct 21, 2005 at 12:59:43AM +0200, Oliver Bandel wrote:
> On Wed, Oct 19, 2005 at 04:35:52PM +0200, Volker Grabsch wrote:
> > On Tue, Oct 18, 2005 at 04:15:57PM +0200, Oliver Bandel wrote:
> > > So frage ich denn: Was soll es mit diesem Projekt auf sich haben?
> > > 
> > > Was willst Du verbessern?
> > 
> > Vielleicht nochmal kurz zur Trennung von Inhalt und Form: Nehmen wir
> > z.B. LaTeX, wo diese Trennung nicht wirklich geglückt ist, und schauen
> > uns an, wie die Mathematiker, Physiker etc. ihre Formeln setzen:
> > 
> >         x \frac{a/b}{c/d}
> > 
> > Das ist ein Bruch, bei dem "a/b" im Zähler, "c/d" im Nenner steht,
> > das ganze multipliziert mit "x". Aber will man das wirklich so genau
> > festlegen? Wenn ich z.B. das hier schreibe:
> > 
> >         x (a/b) / (c/d)
> >  
> > dann habe ich die Formel in eine Zeile gequetscht. Ich könnte auch
> > die Quotienten a/b und c/d jeweils als extra Bruch darstellen:
> > 
> >         x \frac{\frac{a}{b}}{\frac{c}{d}} 
> > 
> > oder vielleicht nach dem "x" einen Multiplikationspunkt setzen:
> > 
> >         x \cdot \frac{\frac{a}{b}}{\frac{c}{d}}
> > 
> > Oder das "x" in den Zähler mit hineinpacken:
> > 
> >         \frac{x \frac{a}{b}}{\frac{c}{d}}
> [...]
> 
> OK, im Prinzip ist dieser Ansatz der Trennung von Form und Inhalt
> sehr sinnvoll - das ist es ja, was mit LaTeX auch geschaffen werden
> sollte (sogennantes WYSIWYM statt sogennantem WYSIWYG).
[...]
> So kann man ja in LaTeX z.B. \emph (statt z.B. \bf oder \it)
> einsetzen. Das bedeutet: Man hat weiterhin die Möglichkeit,
> Auszeichnungen zu markieren, ohne aber im Dokument selbst
> anzugeben, wie es konkret aussieht.

... und trotz Makros leider nicht wirklich erreicht wurde. Aber dafür
ist LaTeX ein vollständiges, sehr gutes Textsatz-System. Man kann eben
nicht beides gleichzeitig haben. Und gerade weil in LaTeX wenigstens
*versucht* wurde, Inhalt und Form schon ein bisschen zu trennen, ist
das auch meine liebste Textsatz-Sprache.

Treibt man die Trennung weiter, kommt man zwangsläufig in die Situation,
nicht mehr alles darstellen zu können. (Deshalb auch WikiDok: Nicht für
Kinderbücher oder Urkunden, sondern für Artikel/Dokumentationen/Handbücher
soll es sein).

Auch die Existenz mehrerer LaTeX-Stylesheets für die Wiki-Sprache finde
ich aus diesem Grund sehr wünschenswert: Es gibt nunmal mehrere
Möglichkeiten, gewisse Wiki-Elemente in LaTeX abzubilden, und dieses
Spektrum gibt dem User eine Wahl.

> > Über all diese Kleinigkeiten macht man sich Gedanken, wenn man eine
> > Formel gutaussehend in LaTeX schreiben will, obwohl das überwiegend
> > formale Aspekte sind! Stattdessen wäre es doch *eigentlich* wünschens-
> > wert, wenn man sich nur auf den Inhalt konzentrieren bräuchte, z.B.
> > indem man einfach schreibt:
> > 
> >         x*(a/b)/(c/d)
> 
> Gerne... :)
[...]
> Aber GANZ auf solcherlei Auszeichnungen zu verzichten
> trifft nicht den Kern der Sache einer Veröffentlichung.
> Das gilt selbstverständlich nicht nur für Fliesstext, sondern
> auch für Formeln. Es kann sehr wohl Sinn machen, bestimmte
> Teile einer Formel hervorzuheben...

Hervorhebung an sich ist ne feine Sache, und (siehe anderen Thread)
habe ich auch nichts dagegen, Teile einer Formel hervorheben zu
können. Das ist auch *inhaltlich* notwendig, auch wenn das aus meinen
Ausführungen wohl nicht hervorging.

> ...da spätestens kann man dann eben nicht mit der Trennung
> von Form und Inhalt weiter machen, denn was der Autor aussagen
> will, kann sehr verschieden sein und deshalb nur vom Autor
> selbst bestimmt werden und nicht von irgend einer Software.
> 
> Da sind dann die Grenzen der Trennung erreicht.

Die Aktion, etwas hervorzuheben, ist doch inhaltlich. Ob dies
aber durch Fettdruck oder roter Farbe oder grünen Hintergrund
passiert, das ist Aufgabe des Stylesheets.

Inhalt und Form lassen sich beim Thema Hervorhebung doch super
trennen!

Übrigens wo wir bei Hervorhebung sind: DocBook geht IMHO etwas
zu weit, wenn dort im Fließtext nur eine Art der Hervorhebung
stattfindet. Betonung (\emph bzw. Kursiv) ist nämlich was anderes
als Schlagworte. Die meisten Leute (nicht alle!) machen es intuitiv
richtig, und gestalten Betonungen kursiv, und Schlagworte fett.
Siehe z.B. Wikipedia. Daher würde ich mindestens zwei Arten der
Hervorhebung einführen, und sofern sie der Stylesheet nicht
farblich hervorhebt, sollten diese durch "kursiv" bzw. "fett"
hervorgehoben werden.

Auf Unterstreichung würde ich (außer vielleicht in Formeln)
verzichten. Als stilistisches Mittel taugt es nicht viel. Aber
ich lasse mich gern eines besseren belehren. Nur, drei Arten
der Hervorhebung sind wohl etwas viel. Da passiert es ganz
schnell, dass man sich nicht entscheiden kann, was "wichtiger"
ist, und zwei wichtige Sachen auf zwei verschiedene Weisen
hervorhebt. Dieser Fehler ist ganz typisch für unerfahrene
Textschreiber, die ohne (stilistische) Anleitung vor ein
WYSIWYG-Textsystem gesetzt werden. (meine Erfahrung nach)


> Im Allgemeinen stimmt das - aber was ist mit Sonderfällen?
> Beispiel: Hervorhebung von Termen von Zähler und Nenner
> zwecks Erklärung von "Kürzungen" eines Bruches in einem Schulbuch?!
> 
> Woher soll die Software wissen, ob es um ein rein mathematisch-forschendes
> Paper (pure Beweisführung ohne besondere Hervorhebung(en))
> geht oder um einen Text, bei dem diverse Sachen in unkonventioneller
> Weise hervor gehoben werden sollen?

Du reitest auch hier auf einem Nicht-Problem, der Hervorhebung,
herum ...

> Da sind dann eben die Grenzen erreicht, und spätestens da braucht
> man eben doch irgendwelche "Hooks".

... und kommst IMHO zum falschen Schluss.

> (Damit will ich aber nicht grundsätzlich die Sinnhaftigkeit Deines/Eures
> Ansatzes in Frage stellen - nur eben Grenzen aufzeigen, wo ein weiteres
> Vorgehen in einer Richtung zu dogmatisch und auch nicht mehr sinnvoll wird...)

Du hast keine echte Grenze genannt. Aber ich stimme zu, dass es welche
gibt. Nur tauchen diese sehr selten auf.

> > 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.
> 
> Ja, aber das ist ein Programm, das einen ganz bestimmten
> Anwendungsfall vorgibt.
> => "wie sie am besten aussieht" meint dann: wie sie am besten für einen
> speziellen layout-fall aussieht, und zwar in diesem Falle das Layout,
> das man benötigt, wenn man Berechnungen durchführen will und das ganze
> "einheitlich" dokumentieren.
> 
> LaTeX ist ein SATZprogramm und kein  auf mathematische
> Beweisführung/Berechnung spezialisiertes Programm,
> und daher gibt es (und muß es auch geben) in LaTeX
> bestimmte spezialisierte Auszeichnungs-Möglichkeiten,
> die in einem Ansatz, wie Du ihnvertrittst allem Anschein nach
> nicht mehr vorhanden wären.

Ganz genau. Aber eben diesen Anwendungsfall habe ich bereits schon
im Namen vorgegeben: Wiki - *Dok*  ...  es geht also um Dokumentationen.
Dieses Feld ist sehr weit (und IMHO das wichtigste), und ich würde es
auch gern noch auf Gedichte und Dialoge (bzw. Drehbücher) ausweiten.
Und es geht vorallem darum, dass die Dokument sowohl Web- als auch
Print-Dokumente sein sollen.

Das heißt, es gibt *natürlich* Grenzen, genau wie z.B. in der Wikipedia.
Aber sie sind weit gesteckt, und wer einen Brief oder ein Musikstück
zu Papier bringen will, für den ist das natürlich nichts.

> > Wenn das ein Automat übernimmt, hat man außerdem gleich einen
> > einheitlichen Stil gewährleistet
> 
> Das kann aber auch nach hinten los gehen und in der Einheits-Soße
> kann man keinerlei Hervorhebungen mehr finden, und damit wird
> das Programm nicht allgemeiner (was man ja möglicherweise auch erreichen will),
> sondern spezialisierter - und damit nur wieder eines unter vielen,
> und man wird dann wieder eine Erweiterung schreiben wollen, die auch
> Auszeichnungen ermöglicht.

Du hackst schon wieder auf der Hervorhebung herum: Diese ist längst
Teil des Konzeptes. Nur eben will ich, dass der Autor einfach sagen
kann: "Diesen Teil der Formel will ich hervorheben" und nicht "das
hier muss grün hinterlegt sein".

Ganz besonders wichtig ist mir übrigens, dass sowohl (X)HTML- als
auch LaTeX-Erzeugung "natürlich" geschehen können. Das ist meine
Meinung nach die wirkliche Herausforderung, die die Wiki-XML-Sprache
vor sich hat: Dass man gleichzeitig ein Web- und ein Print-Dokument
beschreiben kann. Vorallem bei Verweisen (Referenzen, Links, ...) im
Fließtext wird das knifflig.

Wenn mich z.B. nur der XHTML-Output nachher interessiert, sollte ich
z.B. auch MediaWiki oder XDoc nehmen, und es nach gutdünken mit
eigenen XHTML-Befehlen zustopfen. Wer aber auch eine gute Druckversion
braucht, oder wer sich mehr auf Inhalt konzentieren möchte und alles
andere in den Stylesheets erledigen will, für den soll WikiDok das
Werkzeug erster Wahl werden.

Bisher kommt, wie schon erwähnt, nur das Docutils-Projekt mit seiner
reST-Sprache daran.

> XML wurde schliesslich auch als praxistaugliche variante von SGML
> erfunden, um dann auch solche Sachen zu machen, die Du hier 
> möglicherweise ausmerzen willst?
> (erfindest Du SGML neu?)

Ich habe keinen blassen Schimmer, was du mir damit sagen willst.
Kannst du es bitte genauer erklären? Inwiefern läuft das WikiDok-
Projekt auf SGML hinaus?

Ich meine, ich könnte noch verstehen, wenn du mir vorwirfst, dass
ich z.B. DocBook neu erfinde. Aber SGML?? Was hat das damit zu tun?


Übrigens: In der Tat sind meine Ziele ähnlich denen von DocBook.
daher habe ich genau geschaut, woran DocBook gescheitert ist, damit
ich das Wiki-XML-Format besser designen kann. Auch tBook etc. habe
ich mir angeschaut, das korrigiert schonmal zahlreiche Designfehler
von DocBook, geht IMHO aber leider wieder in die falsche Richtung. :-(
Ich hab mir auch nen Haufen anderes Zeugs angesehen, ursprünglich in
der Hoffnung, etwas davon für die Dokumentation eines großen Projektes
benutzen zu können. Aber alles hatte irgendwo einen großen Haken, der
es für mich leider unbrauchbar gemacht hat. :-( ... diesen Recherchen
entstammt übrigens die Liste von Nachteilen, die auf meine WikiDok-
Seite steht. Momentan nehmen wir OpenOffice, das ist noch am besten
geeignet. An zweiter Stelle stünden MediaWiki bzw. DokuWiki. Schon
merkwürdig. Und genau diese Situation möchte ich verändern.


> Das ist dann eher eine DSL für bequeme Dokumentenerstellung als daß
> es damit einfacher wird *alle Möglichen* Texte zu erstellen.

Will ich *alle möglichen* Texte haben, dann *kann* ich gar nicht
Inhalt und Form komplett trennen, weil mir ja sämtliche stlistischen
Mittel zur Verfügung stehen müssen - nicht nur die, die mein Stylesheet
benutzt.

Für diesen Anwendungsfall tun LaTeX, Lout, OpenOffice, etc. ihren
guten Dienst. Das ist *nicht* das Ziel von WikiDok.

> Wenn es eine spezialisertere Sprache (DSL) ist, dann macht es keinen Sinn,
> diese zu entwickeln, wenn sie antritt, viel allgemeiner zu sein;
> aber das ist ja viell. auch garnicht gewollt (weil nicht schwerpunkt)?

Genau!

> > ... was ja sonst eines der größten 
> > Probleme ist, wenn z.B. mehrere Autoren in OpenOffice an einem Dokument
> > arbeiten wollen.
> 
> OpenOffice?
> Was soll das denn jetzt?!

Siehe WikiDok-Seite. uff ... also nochmal:

OpenOffice ist einer der Kandidaten, gegen die ich antrete. Das Projekt
tritt nicht nur gegen alle Wikis an, sondern auch gegen alle anderen
Dokumentations-Systeme ... von LaTeX über XDoc bis hin zu OpenOffice.
Aber weil mir die Wiki-Sprachen vom Konzept her am sinnvollsten schienen
(und sie am besten bewährt haben), geht mein Projekt scheinbar in die
Richtung, dass ich ein Wiki schreiben will. Das stimmt aber nicht. Ich
will keine Weboberfläche, sondern "nur" ein Filtersystem haben, das aus
editorfreundlichen Wiki-Sprachen, einem Parser/Transformations-freundlichem,
gut designten XML-Format dafür, und einem Stylesheet-System besteht.

Dabei möchte ich so viel wie möglich wiederverwenden, z.B. das LaTeX-
System (PDF-, PS-Erzeugung), falls möglich die Parser-Routinen der
Wikis, und vielleicht sogar deren HTML-Erzeugung. Aber natürlich alles
als Filter, also per Kommandozeile über Dateien bzw. stdin/stdout.

Dass ich außerdem noch eine eigene Wiki-Sprache entwickeln will, die
besser ist als DokuWiki und MediaWiki, das tritt dabei in den
Hintergrund, auch wenn es die ursprüngliche Motivation für das Projekt
war. Aber ich wollte halt nicht "yet another wiki" schreiben, sonst
verzapfe ich den selben monolithischen Mist wie die anderen Wikis.

> > Ein ganz klassisches analoges Problem in der Wikipedia: Die Tabellen
> > sehen entsetzlich aus. Statt HTML-Code bzw. CSS-Einträge vorzunehmen,
> > sodass die Tabellen z.B. so gut wie beim DokuWiki aussehen, haben sie
> > <table>-Attibute in der Wikisprache erlaubt.
> 
> Was wäre stattdessen sinnvoll?

Bitte lies den Satz nochmal.


Grundproblem:
Tabellen sehen scheiße aus.

---> nicht sinnvolle Lösung (MediaWiki):
	<table>-Attibutee werden innerhalb der Wikisprache erlaubt.

---> sinnvolle Lösung (DokuWiki):
	Der Stylesteet erzeugt gutaussehende Tabellen.


Nun klar? Soll ich in Zukunft vielleicht meine Sätze wie ein Programm
einrücken? So tief verschachtelt sind sie ja nun auch nicht. Es war
nur eine "Statt ..., haben sie ... gemacht" - Konstruktion.


> > Das Resultat: Die
> > Wikipedianer verschwenden (unter anderem) ihre Zeit damit, in den
> > Tabellen für jede Zelle eine ordentliche Hintergrundfarbe zu setzen,
> > die breite der Tabellen-Linien festzulegen, u.s.w.
> 
> Nun, das viele herum-gewurschtel im layout ist sicherlich in 95% (oder mehr)
> der fälle unsinnig.
> Aber eine gute Typographie braucht auch die Möglichkeit, in besonderen
> Fällen Hervorhebungen zu erlauben.

Schon wieder Hervorhebungen. Und nochmal: Das widerspricht meinem
gesagten nicht.

> > Umgekehrt findet sich keiner, der in den Stylesheets für gutaussehende
> > Tabellen sorgt, weil es viel "einfacher" ist (d.h. eine viel geringere
> > Lern-Hürde darstellt), diese Sachen innerhalb der Wikisprache zu
> > erledigen.
> 
> Nun - statt das Wiki-Rad neu zu erfinden, warum entwickelst du dann
> nicht solche Stylesheets, so daß alle sie fortan nutzen können?

Weil das beiweitem nicht das einzige Problem ist. Die gesamte
Architektur ist monolithischer Schrott. Die CSS-Dateien scheinen das einzige
wirklich austauschbare an der Sache zu sein. :-(

Davon abgesehen schreibt mir MediaWiki vor, meine Dateien in ner MySQL-
Datenbank mit selbstgestrickter (MediaWiki-spezifischer)
Versionskontrolle und selbstgebauter Rechteverwaltung zu halten.

*Wenn* ich das MediaWiki um irgendwas erweitere, dann um ein
Kommandozeileninterface, welches einem beliebige Dateien mit
MediaWiki-Code in das MediaWiki-XML-Format bzw. in XHTML umwandelt.
Dann könnte man das MediaWiki wenigstens *wirklich* gebrauchen.

Die Wikis haben drei wertvolle Komponenten: Das Webinterface, den
Parser der Wikisprache, und die (X)HTML-Erzeugung. Alles andere sollten
sie Software überlassen, die sich damit auskennt.

Mein Ziel ist es, eine Architektur zu erschaffen, die diese 3 Bereiche
aufteilt. Und da man das MediaWiki oder DokuWiki nicht einfach
"auseinanderreißen" und "neu zusammenstecken" kann, muss ich eben die
Infrastruktur dafür liefern. Und zwar, *ohne* einen Monolithen zu
erschaffen. Und hier trennt sich die Spreu vom Weizen: Leidiglich
das Docutils-Projekt hat das geschafft, mit einer interessanten
Architektur, die stark von meinem Ansatz abweicht. Das ist die einzige
Stelle, wo ich wirklich am Grübeln bin, ob ich stattdessen nicht beim
Docutils-Projekt mithelfen könnte. Aber deren Architektur hat ein paar
starke Nachteile ...

> Ist dies nicht Dein Ansatz, den Du immer hervor bringst?
> Also, das vorhandene (Stylesheets) zu nutzen, statt anderes
> (eine WikiSprache) neu zu erfinden?
> Greife doch auf das zurück, was bersits da ist!

Ich habe doch vor, MediaWiki zu unterstützen! Nur ist es eines meiner Ziele,
*wiederverwendbare* und *austauschbare* Stylesheets zu haben.

Schau in meine Skizze. Von Anfang an existiert auch ein Rückweg
"Wiki-XML-Format" nach "Wikisprachen". Zum einen, um das Editieren
besser zu ermöglichen, zum anderen, um die vorhandenen Stylesheets
für bisherige Wiki mit nutzen zu können.

Was ich da mache, ist quasi das Analogon zu meinem Vorschlag, deine
Laban-DSL sollte eine Teilmenge von z.B. LaTeX sein.

> ich hoffe, es ist auch klar geworden, daß eine VOLLKOMMENE
> Trennung von Form und Inhalt via WikiDoku-Sprache && Konverter-SW
> nicht wirklich zu dem führen kann, was man will.

Das wage ich zu bezweifeln. Man muss es nur richtig[tm] machen. :-)

Ich sehe das so ähnlich wie mit Unix und dem Prinzip "alles sind
Dateien".

Da meint man auf einmal: Halt! Es gibt doch noch Devices, die etwas
anders behandelt werden müssen. Und "tty"s, die anders. Und Prozesse
bzw. Threads sind nochmal was völlig anderes. Und so blähte sich
die Unix-API auf. Sie war immer noch die beste Architektur, aber
es wurden Probleme an der falschen Stelle angegangen.

Mittlerweile gibt es andere Systeme, z.B. Plan9. Da ist *wirklich*
alles eine Datei. Korrekter gesprochen: Sämtliche Interprozess-
Kommunikation läuft über virtuelle Dateisysteme. Du willst alle
Prozesse sehen? Das ist ein Verzeichnis! Reinschauen, jede Datei
ist ein Prozess. Du willst ihn killen? Lösch die Datei. Devices
und TTYs verlieren ihren Sonderstatus: Jetzt kann man endlich
Dateien mounten, ohne dafür ein extra Loopback-Device zu erzeugen.
Und so weiter... Ich will jetzt nicht weiter ausholen, dazu habe
ich mich noch zu wenig mit Plan9 beschäftigt. Tatsache ist aber,
dass sie den Begriff der Datei etwas "weiter" gefasst haben, und
sehr kreativ sein mussten, aber sie haben es geschafft. Nach wie
vor gilt: Nicht alles ist eine Datei. Aber sie können viel mehr
darstellen, als man zunächst glaubt. :-)


Bezogen auf WikiDok meine ich: Ja, sicher wird man es mit der
Zeit um einige Elemente noch erweitern müssen. Vielleicht stößt
man auch irgendwann an eine Grenze, wo es entweder um einen
Anwendungsfall geht, der nichts mehr mit Dokumentationen zu tun
hat, dann muss man sich dagegen abgrenzen. Oder jemand will die
XHTML-Ausgabe im Detail kontrollieren - dann soll er XDoc nehmen.
Aber ich bin der Meinung, dass man die Trennung viel stärker
machen kann (und sollte), als es bisher geschieht, und dass dies
genau das ist, was man will[tm]. :-)

Es muss einfach zwei Schichten geben: Inhalt und Stylesheet, und
der Stylesheet darf dabei nicht unter den Tisch fallen. Man muss
die Probleme besser verteilen: Löse ich es nun im Stylesheet oder
im Inhalt? Und ich bin mir sicher, dass diese tollen "beliebiger
XHTML / LaTeX - Code mitten im Inhalt" ein riesiger Designfehler
ist, weil man sich einfach um diese wichtige Frage drücken will,
statt sie zu klären.

Würde hingegen aktiver am Stylesheet gearbeitet werden können,
was sich aber nur lohnt wenn es nicht zu schwer ist und nicht
wiki-spezifisch, dann würde das IMHO zu sehr viel eleganteren
Lösungen führen.

Wenn z.B. die stilistischen MediaWiki-Features zu, sagen wir, 95%
missbraucht werden, würde ein Abschaffen dieses Missbrauchs dazu
führen, dass a) die Stylesheets besser werden, weil all die pingeligen
Fanatiker (wie z.B. ich :-)) an den Stylesheets helfen würden, statt
ihre Wiki-Dokumente zu entstellen/verkrüppeln. Die restlichen 5%,
die sich damit nicht lösen lassen, würden zu Feature-Requests werden,
die echte Verbesserungen in der Sprache nach sich ziehen.

Der Status-quo, dieses Problem umgehen zu können, verhindert IMHO
diese Entwicklung, was zu den zahlreichen Missbildungen in den Wiki-
Sprachen geführt hat.

> > Die "zentrale Wiki-XML-Sprache"
> > (ich hab sie erstmal WikiDoXML genannt), wird erstmal keine
> > stilistischen Details ermöglichen.
> 
> Es sollte aber Auszeichnungsmöglichkeiten geben, auch wenn die
> Details der Auszeichnungen nicht im Dokument selbst festgelegt
> werden können (siehe Erwähnung mit \emph vs. \bf bzw. \it usw.)

Wiegesagt: Meine Rede. Genau das meine ich doch auch.


Viele Grüße,

	Volker

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