Michael Schröpl: Vorschlag: SelfWiki

Beitrag lesen

Ich sehe das Wiki halt nicht als Konkurrenz fürs Forum, sondern als Konkurrenz für die Doku. Und der Punkt ist halt, daß es so einiges gibt, was bereits in der Doku fehlt (im Prinzip ist das mit der V8.1 verbesserte Kapitel über DOM ja immer noch arg unvollständig - an das von 8.0 denke ich nur mit Grausen - und 9.0 ist nicht in Sicht).

Je länger ich über das Thema nachdenke, umso mehr empfehle ich Dir, tatsächlich mal einen SelfHTML-to-MediaWiki-Crosscompiler zu schreiben - einfach nur, um zu sehen, inwiefern die beiden Semantik-Universen zueinander kompatibel sind. Die Schwierigkeit steckt dabei nicht im Parsen der Dokumente (so etwas kann Perl ziemlich ordentlich), sondern im Aufstellen einer Abbildung zwischen den jeweiligen Konzepten.

Stell Dir ein Perl-Skript vor, das nacheinander über alle HTML-Dateien von SelfHTML drüberfährt und zu jeder von ihnen eine Textdatei mit MediaWiki-Code generiert. Stell Dir ein zweites Perl-Skript vor, das mit HTTP-Post alle so generierten Textdateien plus die bereits existierenden Bilddateien in ein existierendes, leeres Wiki hinein pumpt. Was müssten diese beiden Skripte können, um ein "SelfHTML-Wiki" zu generieren? Und was können sie _nicht_ schaffen?

Zunächst einmal lassen sich die SelfHTML-Dateien nicht einzeln "kompilieren". Einer ihrer größten "Schätze" sind nämlich die zahlreichen internen relativen Links. MediaWiki enthält ein "kompatibles" Konzept dafür - aber das geht über den Entity-Namen, nicht den Dateinamen. Bei HTML ist der Dateiname frei wählbar und unabhängig vom Inhalt des <title>-Tags bzw. des Inhalts des <h1>...</h1>-Tags; bei MediaWiki sind beide aber identisch AFAIK. Der Crosscompiler müsste also zunächst einmal über alle HTML-Dokumente drüberfahren und eine Übersetzungstabelle zwischen HTML-Dateinamen und HTML-Dokumenttiteln (den späteren Wiki-Entity-Namen) erstellen, mit deren Hilfe er (oder ein anderes Skript) im zweiten Durchgang sämtliche relativen Links passend umschreiben könnte. Hinzu kommt, dass Du die Kapitel-Hierarchien in HTML, also die <h1>... <hn>, auf korrespondierende MediaWiki-Hierarchien abbilden wollen würdest, welche dann wiederum automatisch als Link-Ziele zur Verfügung stehen würden... der erste Durchgang würde also einen riesigen Übersetzungs-Hash aufbauen.
Tabellen in HTML lassen sich als Tabellen in MediaWiki umsetzen - da muss im Wesentlichen anderer Code generiert werden, das geht aber vermutlich kontextfrei. Graphiken sind sowohl für die HTML-Version als auch für die MediaWiki-Version separate Dateien; allerdings funktioniert die relative Adressierung anders, und auch in Sachen Einbindung geht eventuell nicht alles exakt gleich. SelfHTML besitzt eine Verzeichnisstruktur für seine Dokumente; diese wird im MediaWiki kein direktes Äquivalent finden, muss aber vom Parser ggf. berücksichtigt werden, um die Links korrekt zu parsen. SelfHTML realisiert seine Optik im Wesentlichen durch CSS; MediaWiki erlaubt zentrale CSS-Definitionen, aber diese sollten sich im Wesentlichen auf HTML-Elemente beziehen und nicht auf Klassen, weil man beispielsweise beim Umsetzen eines <p> nach Wiki keinen Code generiert, dem man eine CSS-Klasse als Attribut anheften möchte (nämlich überhaupt nichts, was nach HTML aussieht). Vor allem will man ja zwischen Layout und Content möglichst gut trennen, und diese Trennung müsste sehr wahrscheinlich noch viel strikter erfolgen, als dies in SelfHTML bisher umgesetzt ist - sonst hat man bei der ganzen Umsetzung nach Wiki nicht viel gewonnen, wenn wieder jeder Bearbeiter den kompletten CSS-Layout-Kram aus dem Effeff beherrschen muss. Umgekehrt gibt es im Wiki-Universum Konzepte, die in SelfHTML bisher nicht verwendet wurden (z. B. Kategorien); könnte man mit denen etwas semantisch Sinnvolles für SelfHTML erreichen, und welchen Code müsste man dafür wo und mit welchem Kontextwissen generieren? Solche Überlegungen sind es, die der Entwickler eines entsprechenden Crosscompilers automatisch durchführen müsste: Wie gut passen die Semantiken zusammen? Was lässt sich abbilden (und wie funktioniert das), und was würde verloren gehen?
Man kann natürlich einfach die HTML- und die MediaWiki-Spezifikation nebeneinander legen und vergleichen, aber das bringt im vorliegenden Fall wenig: Der größte Teil von SelfHTML verwendet eine relativ kleine Teilmenge von HTML (plus bestimmte interne "Hausregeln" bei der Verwendung von CSS), welche der sehr viel weniger mächtigen Semantik von MediaWiki gar nicht mal völlig unähnlich ist. Insofern denke ich, dass ein Crosscompiler vielleicht 80-90% der Umstellungsarbeit leisten könnte; die Schwierigkeiten fangen wahrscheinlich dort an, wo SelfHTML seine "HyperBuchform" verlässt und selbst zur Web-Applikation wird, nämlich bei den zahlreichen eingebundenen Beispielen. Und beim Schreiben eines solchen Crosscompilers, dessen Umwandlungsergebnisse man Datei für Datei manuell kontrolliert, kann man sich von Anwendungsfall zu Anwendungsfall vorantasten. Ein <p> oder <li> nach MediaWiki umzusetzen ist (relativ) trivial; was aber mache ich mit einem <form>? Was mit einem <object>? Der entsprechende Dokument-Parser würde HTML-Element um HTML-Element und CSS-Klasse um CSS-Klasse wachsen und einen immer größeren Teilbereich der SelfHTML-Dateien übersetzen lernen - und was übrig bleibt, das sind dann die echten Problemfälle.
Wichtig ist, dass der Parser gar nicht erst versuchen sollte, komplettes HTML zu parsen, sondern wirklich nur genau das, was von SelfHTML und den Feature-Artikeln tatsächlich benutzt wird - beispielsweise keine beliebig tiefen Schachtelungen von Tags. Die 90%-Lösung ist hier sicherlich deutlich billiger als die 99%-Lösung - und für eventuelle Nacharbeiten soll ja angeblich das viele zusätzlich anzuwerbende Personal mit der niedrigen Einstiegsbarriere verfügbar sein. ;-)

So würde ich an die Sache herangehen, wenn ich SelfHTML in ein Wiki "stopfen" wollen würde. Ich würde SelfHTML nicht als Buch ansehen, sondern als _Datenstruktur_. Mit derselben Herangehensweise habe ich damals die Indexer für die Suchfunktion gebaut.
Schreibe einen solchen Crosscompiler, installiere MediaWiki auf einem nicht allgemein sichtbaren Server, konvertiere SelfHTML und zeige dem Developer-Team das Ergebnis. Dann hast Du eine ganz andere Diskussionsbasis als jetzt - und gleichzeitig ein viel besseres Gefühl für die Grenzen des Umsetzbaren.

0 83

Vorschlag: SelfWiki

Gunther
  • zu diesem forum
  1. 0
    O'Brien
    1. 0
      Gunther
      1. 0
        Orlando
        1. 1
          Gunther
          1. 0
            Orlando
            1. 0
              lina-
            2. 2
              Stefan Muenz
              1. 0
                lina-
                1. 0
                  Der Martin
                2. 0
                  Stefan Muenz
                  1. 0
                    lina-
                  2. 0
                    Johannes Zeller
              2. 0
                Gunther
            3. 0
              Gunther
              1. 1
                Jens Müller
                1. 0
                  Der Martin
                  1. 0
                    Gunnar Bittersmann
                    • menschelei
                    1. 0
                      Der Martin
                  2. 0
                    Jens Müller
              2. 0
                Detlef G.
              3. 0
                Orlando
  2. 0
    doni
    1. 0
      doni
  3. 4
    Sven Rautenberg
    1. 0
      dey
      1. 0
        Jens Holzkämper
        1. 0
          dey
          1. 1
            Sven Rautenberg
    2. 0
      Gunther
      1. 2
        Sven Rautenberg
        1. 1
          Gunther
    3. 1
      Heizer
      1. 0
        Gunther
    4. 0
      Cybaer
      1. 0
        Swen Wacker
        1. 0
          Cybaer
  4. 4
    Swen Wacker
  5. 9
    Stefan Muenz
    1. 0
      lina-
      1. 0
        Stefan Muenz
        1. 0
          lina-
      2. 0
        Swen Wacker
    2. 0
      Gunther
    3. 0
      Ilja
      1. 1
        Christian Kruse
    4. 0

      Verbindung von Doku - Wiki - Forum

      Felix Riesterer
      1. 1
        Stefan Muenz
        1. 0
          Dennis
  6. 5
    Michael Schröpl
    1. 0
      Cybaer
      1. 1
        Michael Schröpl
        1. 1
          Cybaer
          1. 0
            Michael Schröpl
            1. 0
              Swen Wacker
              1. 0
                Michael Schröpl
                1. 0
                  Ingo Turski
                2. 0
                  Tim Tepaße
                  1. 0
                    Michael Schröpl
                3. 0
                  Swen Wacker
                  1. 0
                    Michael Schröpl
                  2. 0
                    Cybaer
                    1. 0
                      Wilhelm Turtschan
                4. 0
                  Cybaer
            2. 0
              Cybaer
              1. 0
                Michael Schröpl
                1. 0
                  Alexander Brock
                2. 0
                  Swen Wacker
                3. 0
                  Cybaer
          2. 0
            Michael Schröpl
            1. 1
              Stefan Muenz
              1. 0
                Michael Schröpl
              2. 0
                Detlef G.
            2. 0
              Tim Tepaße
              1. 0
                Michael Schröpl
            3. 0
              Cybaer
              1. 0
                Michael Schröpl
                1. 0
                  Cybaer
        2. 0
          Swen Wacker
      2. 0
        Ingo Turski
        1. 0
          at
          1. 0
            Ingo Turski
        2. 0
          Cybaer