@BlackJack: Dieser Vorwurf steht allerdings –wie Du selbst festgestellt hast – unter der Prämisse, dass beide Formate auch tatsächlich demselben Zweck dienen.
Docbook erfüllt denselben Zweck wie ReST allerdings nur insofern, wie auch Python im Allgemeinen denselben Zweck wie Java oder C# erfüllt. Beides sind Auszeichnungssprache für Dokumentation. Ob beide aber konkret gleichermaßen zweckdienlich sind, hängt eben von den konkreten Anforderungen ab. ReST ist beispielsweise alles andere als zweckdienlich, wenn man es mit Java verarbeiten muss, während das bei Docbook keine sonderlich große Herausforderung wäre.
Deswegen – ich habe das Gefühlt, ich wiederhole mich – sollte man die Entscheidung gegen ein XML-basiertes Format auf einer fundierteren Basis als persönlicher Abneigung treffen, denn es gibt eben im Allgemeinen genügend viele Situationen gibt, in denen man um Docbook (oder XML im Allgemeinen) nicht herumkommt, oder es sich als für die konkreten Erfordernisse eben als am zweckdienlichsten erweist. Das – und nichts anderes – ist Inhalt und Aussage meiner Beiträge.
Sphinx für "normale" Dokumentation verwenden?
-
BlackJack
@lunar: Der gemeinsame Zweck ist durch das Thema hier vorgegeben und lautet ganz allgemein Dokumentation schreiben. Mit dem Zusatz, dass verschiedene Formate wie HTML, E-Books, und etwas Druckbares hinten raus fällt. Und da kann man selbstverständlich eine auf Erfahrungen basierende „persönliche” Abneigung gegen XML-Formate als Grund anführen.
Es gibt auch Gründe PHP einzusetzen. Was die Sprache nicht besser macht.
Es gibt auch Gründe PHP einzusetzen. Was die Sprache nicht besser macht.
Irgendwie ist die Diskussion sophistisch. Mit den richtigen Tools wird jedes Format händelbar, wie z.B. der Browser zeigt. Mit dem richtigen Editor/IDE wäre selbst Brainfuck zu bewältigen (oder XSLT 
). Das Openoffice im Hintergrund XML nutzt, interessiert außer die Developer niemanden. Das Tool funktioniert nach vorne gut genug im Dau-Sinne, dass jeder mehr oder weniger damit zu Rande kommt. Selbiges könnte man auch für Docbook erreichen. Für den Anwender ist doch eigentlich nur die Güte der Schnittstelle entscheidend.
Simples Bsp. aus Python - wer versucht schon, pickle-Dateien "von Hand" zu schreiben - die Schnittstelle macht, was sie verspricht, ergo geht man darüber. Niemand versucht, pickle auf Repräsentationsebene zu verstehen. pickle könnte genauso gut die Daten im XML-Format gleicher Mächtigkeit ablegen, einziger Unterschied wäre neben erhöhtem Verarbeitungsaufwand, dass Leute versuchen würden, dieses XML-Format zu verstehen. Und stöhnen - uff ist das kompliziert. Imho ist das die Krux von XML, es versucht, gerade noch menschenlesbar zu sein und dabei Maschinenlesbarkeit/Austauschbarkeit zu gewährleisten, was XML in Rohform (also ohne das "richtige" Tool) näher zur Maschine rückt als zum Anwender, der ein Problem umzusetzen hat und mit einer speziell auf das Problem zugeschnittenen Sprache in dessen Rohform vllt. eleganter zum Ziel kommt.
Was ist lesbarer: SCNR
NB: Auch wenn sich das vllt. wie XML-Promotion liest, bin ich selbst kein großer XML-Fan und greife gerne auf simplere Lösungen zurück (Bsp. JSON). Das ist aber eher den Tatsachen geschuldet, dass XML in der Regel sehr viel teurer in der Verarbeitung ist bzw. das entsprechende Tool für XML-Format xy fehlt. Den Standardisierungsansatz finde ich nach wie vor bestechend.
). Das Openoffice im Hintergrund XML nutzt, interessiert außer die Developer niemanden. Das Tool funktioniert nach vorne gut genug im Dau-Sinne, dass jeder mehr oder weniger damit zu Rande kommt. Selbiges könnte man auch für Docbook erreichen. Für den Anwender ist doch eigentlich nur die Güte der Schnittstelle entscheidend.Simples Bsp. aus Python - wer versucht schon, pickle-Dateien "von Hand" zu schreiben - die Schnittstelle macht, was sie verspricht, ergo geht man darüber. Niemand versucht, pickle auf Repräsentationsebene zu verstehen. pickle könnte genauso gut die Daten im XML-Format gleicher Mächtigkeit ablegen, einziger Unterschied wäre neben erhöhtem Verarbeitungsaufwand, dass Leute versuchen würden, dieses XML-Format zu verstehen. Und stöhnen - uff ist das kompliziert. Imho ist das die Krux von XML, es versucht, gerade noch menschenlesbar zu sein und dabei Maschinenlesbarkeit/Austauschbarkeit zu gewährleisten, was XML in Rohform (also ohne das "richtige" Tool) näher zur Maschine rückt als zum Anwender, der ein Problem umzusetzen hat und mit einer speziell auf das Problem zugeschnittenen Sprache in dessen Rohform vllt. eleganter zum Ziel kommt.
Was ist lesbarer:
Code: Alles auswählen
<header>Überschrift</header>
= Überschrift =NB: Auch wenn sich das vllt. wie XML-Promotion liest, bin ich selbst kein großer XML-Fan und greife gerne auf simplere Lösungen zurück (Bsp. JSON). Das ist aber eher den Tatsachen geschuldet, dass XML in der Regel sehr viel teurer in der Verarbeitung ist bzw. das entsprechende Tool für XML-Format xy fehlt. Den Standardisierungsansatz finde ich nach wie vor bestechend.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Haha, falsch. SCNR, aber der Artikel als solches ist interessant und zeigt auf dass ein vergleichbares XML-Format eine Stacksprache definieren müsste. Vielleicht kann man auch XSLT soweit biegen da was vergleichbares rausfällt.jerch hat geschrieben:Niemand versucht, pickle auf Repräsentationsebene zu verstehen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Hehe, schönes Ding. Mit XSLT hat XML den Fuß in der Programmiersprachentür (turing-vollständig), daher sollte das möglich sein. Freiwillige vor für einen veregneten Samstag?Leonidas hat geschrieben:Haha, falsch. SCNR, aber der Artikel als solches ist interessant und zeigt auf dass ein vergleichbares XML-Format eine Stacksprache definieren müsste. Vielleicht kann man auch XSLT soweit biegen da was vergleichbares rausfällt.
