Am Montag, den 31.10.2005, 16:51 +0100 schrieb Patrick Willam: > Holger Levsen schrieb: > - 1. - > > Es ging/geht nicht um SGML, es ging/geht um DocBook (XML). Was für praktische Zwecke wenig Unterschied macht. > - 2. - > > Man koennte den DocBook-Quelltext prinzipiell direkt im Wiki pflegen; > ueber die Anbindung eines XSLT-Prozessors an MoinMoin. > Im Editierfeld hat man dann statt Wiki-Markup direkt XML; beim Abruf so > einer Wikiseite wird ueber den Prozessor die entsprechende bzw. gewohnte > Wiki-HTML-Darstellung erzeugt. Bleibt die Frage nach der Performance und die Frage nach multiplen Ausgabeformaten. > Da das fuer MoinMoin erhaeltliche XSLT-Plugin aber die Referenzierung bzw. > Einbindung lokaler Dateien (was in XML/DocBook erlaubt ist) nicht speziell > ausschlieszt, wuerde der Einsatz dieses Plugins den Zugriff auf *alle* > normal lesbaren Dateien auf der Festplatte von Skolelinux.de ermoeglichen. > Kurz gesagt: groszes Sicherheitsloch. Von dem Alptraum will ich gar nicht träumen... Aber leider liegt Patrick da richtig. In Zope/Plone ist das etwas besser gelöst. > Auszerdem soll ja nicht jeder erst XML/DocBook lernen muessen! Bei einer Lösung SVN/Makefiles, die sich anbahnen könnte ließe sich das nicht umgehen, diese hätte aber keine Nachteile gegenüber den angesprochenen CMS/Wiki-Lösungen, so wie sie sich augenblicklich darstellen. > (Ein von mir und David getestetes spezielles DocBook-Wiki hat sich -- nicht > nur bzgl. der Dokumentation, sondern generell -- als untauglich erwiesen.) Ich erinnere mich an dieses PHP Monster. > - 3. - > > David hatte einen Weg erarbeitet/skizziert/vorgeschlagen, bei dem Transfor- > mationsprozesse von Wiki-Markup ueber ReST-Markup nach DocBook-Markup (und > wieder zurueck) wandeln. Diese waeren dann 'backstage' jeweils anzustoszen. Noch hoffe ich, dass es leichter geht. > _Soweit_ich_ weisz_, lagen/liegen einer laufenden Implementierung noch > folgende Umstaende im Weg: > > a) > Ein DocBook-Dokument ist (inhaltlich/semantisch/technisch) mehr, als eine > oder viele Wiki-Seiten oder die Summe davon. Daher reicht es nicht, nur > das Markup zu transformieren. Man braucht noch zusaetzliche Infrastruktur; > und diese war bei unseren Recherchen 'seinerzeit' bisher nicht zu finden, > d.h. sie musz/mueszte von uns erst selber erstellt werden. Im wesentlichen ist das Problem, dass DocBook nach ReST nur verlustbehaftet konvertiert werden kann, d. h. man kann nur mit einem kleinen subset der Sprache arbeiten, die von beiden Formaten abgedeckt ist. > b) > David hat seine Zeit, die er in das Projekt einbringt, zunaechst der Doku- > Uebersetzung & deren Koordinierung, der neuen Doku (fuer "sarge") & deren > Uebersetzung & Koordinierung, der Systematik der PDF-Erstellung (aus > DocBook) und nicht zuletzt dem neuen Build-System gewidmet. > Auszerdem hat er auch den Plone-Versuch auf skolelinux.de betreut, wo es > u.A. auch darum ging, einen entsprechenden Workflow fuer die Dokumentation > aufzusetzen, basierend auf der leistungsfaehigeren Plone/Zope-Architektur. > Dieser Versuch wurde von David beendet mit dem Ergebnis, dasz diese Basis > auch nicht ohne zusaetzl. tiefergehende Entwicklung das Geforderte leistet. > > c) > Es gibt also noch keinen fertigen Code bzw. "glue", der die Luecke(n) > zwischen den Teilen/Techniken/Arbeitsschritten praxisgerecht fuellt. Patrick liegt hier leider 100%ig richtig. Fest steht, es wird eine Lösung für dieses Problem geben, da es viele an dieser Stelle juckt. Die großen Projekte, wie Ubuntu oder KDE, die auch auf DocBook setzen, nehmen alle CVS/SVN Repositories (Depots *g*) und wenden viel Arbeitskräfte/-zeit auf. Viele Grüße David
Attachment:
signature.asc
Description: This is a digitally signed message part