In der Software-Welt dominiert Markdown. README, API-Dokumentation, Blog, Wiki, alles in derselben einfachen Syntax. In Branchen mit komplexen Produktwelten, Mehrsprachigkeit und länderspezifischen Filtern sieht die Werkzeugkiste anders aus. Dort arbeitet seit Jahrzehnten ein XML-Standard namens DITA, der in der IT-Welt fast unbekannt ist und bestenfalls denjenigen ein Begriff ist, die Kundendokumentation für sehr komplexe Softwareprodukte erstellen.
Dieser Artikel ordnet DITA und Markdown nüchtern ein, beschreibt, wann strukturierte Dokumentation ihren Aufwand rechtfertigt, und skizziert hybride Pipelines, die das Beste aus beiden Welten verbinden.
Was DITA ist und warum es weiterlebt
DITA steht für Darwin Information Typing Architecture, ein vom OASIS-Konsortium gepflegter XML-Standard. Inhalte werden nicht als freier Text geschrieben, sondern als typisierte Bausteine. Kleine Kapitel (Topics), die in einer Map zu einem Dokumentationsprodukt zusammengefügt werden, gibt es in den Typen Concept (Beschreibung), Task (Handlungsanleitung) und Reference (Detailinformationen in Tabellen oder Listen). Unterbausteine sind dann zum Beispiel Überschrift, Absatz, Warnhinweis oder Grafik. Jeder Baustein folgt einer festen Struktur, kann mit Metadaten versehen werden und über Filter ein- oder ausgeblendet werden. Typisierung und Identifikation der einzelnen Textbausteine und weiteren Medieninhalten ermöglichen deren Wiederverwendung in unterschiedlichsten Ausgaben der Dokumentation.
Wer ein Auto-Handbuch schreibt, schätzt diese Kombination aus Filtern und Re-Use. Denn bestimmte Sicherheitsanweisungen erscheinen nur in der japanischen Edition, ein spezieller Hinweis nur bei Modellpflegestand 2025 und für Länder mit Rechtsfahrgebot müssen eigene Grafiken eingebunden werden, in denen das Lenkrad auf der rechten Seite des Autos zu sehen ist. Dabei bleiben trotzdem weite Teile des Contents über unterschiedlichste Ausgaben hinweg ähnlich. Die hierfür gebotene Modularität ist in einer Markdown-Welt nur mit erheblichem Workaround-Aufwand zu erreichen.
Auch in Software-Organisationen, die mehrsprachige Produkte mit hoher Release-Frequenz betreiben, ist DITA produktiv im Einsatz. Häufig hinter verschlossenen Türen, weil es im Diskurs außerhalb der Tech-Writer-Community kaum sichtbar ist.
Wo Markdown gewinnt
Markdown gewinnt überall dort, wo Schreibgeschwindigkeit zählt und Komplexität moderat bleibt. Pull-Requests gegen Markdown-Dateien sind in jeder Engineering-Pipeline sofort verständlich, Diff-Werkzeuge funktionieren ohne Konfiguration, jeder Editor unterstützt Live-Preview. Im Gegensatz zu DITA muss nicht zwangsweise ein komplexes Content Management System (CMS) eingeführt werden.
Markdown gewinnt auch bei kurzlebigen Inhalten. Blog-Posts, Onboarding-Notizen, ADR-Dokumente, README-Dateien. Dort bremst die Strukturschwere von DITA mehr, als sie nutzt.
Markdown gewinnt schließlich in der Brücke zur KI. Embedding-Pipelines, RAG-Systeme und LLM-Promptings arbeiten mit Markdown nativ. DITA-XML braucht eine Vorverarbeitung, die nicht in jedem Stack vorhanden ist. Wer ein RAG-System aufbaut, beginnt typischerweise mit Markdown-Quellen, wie wir es im Artikel zu RAG-Systemen im Unternehmenseinsatz beschrieben haben.
Wo strukturierte Dokumentation gewinnt
Mehrsprachigkeit Wer pro Release fünf, zehn oder zwanzig Sprachen ausliefert, profitiert von der strikten Trennung von Inhalt und Variante. Translation-Memory-Systeme arbeiten zuverlässiger gegen typisierte Bausteine als gegen freie Markdown-Abschnitte.
Variantenvielfalt Produktfamilien mit länder-, modell- oder lizenzspezifischen Varianten lassen sich mit DITA-Filtern sauber managen. Markdown verlangt entweder Duplikate oder fragile Template-Engines.
Compliance-relevante Dokumentation Wo Dokumentation rechtlich Teil des Produkts ist und Audit-Spuren entstehen müssen, schlägt eine strukturierte Quelldatei mit klarem Schema einen freien Markdown-Text. Auch im Bereich Security-Dokumentation gilt das, wie wir in unserem Beitrag zu DevSecOps versus DevOps angerissen haben.
Hybride Pipelines
Die ehrliche Antwort lautet selten “DITA oder Markdown”, sondern “DITA und Markdown”. Drei Hybrid-Muster haben sich in Projekten bewährt.
1: Markdown als Eingangsformat, DITA als Speicher. Subject-Matter-Experts und Entwickler liefern Markdown, eine Pipeline konvertiert in DITA-Topics für die finale Veröffentlichung. Das Eingangsformat bleibt entwicklerfreundlich, das Speicherformat trägt die Variantenlogik.
2: DITA für Produktdokumentation, Markdown für Begleit-Inhalte. Anleitungen, Sicherheitshinweise und Compliance-Dokumentation in DITA; Blogs, Tutorials und Release Notes in Markdown. Beide Welten existieren parallel, mit klaren Zuständigkeiten.
3: DITA als Quelle, Markdown als Render-Output. Eine DITA-Map wird per Toolchain in HTML, PDF und Markdown gerendert. Markdown dient als Eingangsformat für Embedding-Pipelines, das LLM erhält strukturell saubere Inhalte ohne XML-Rauschen.
Was die Wahl praktisch entscheidet
Die folgenden sechs Fragen helfen bei der Tool-Wahl.
Wie viele Sprachen liefert das Produkt?
Schon bei mehr als zwei Output-Sprachen kann es mit Markdown schon zu komplex werden.
Wie viele Varianten existieren pro Release?
Je mehr Varianten, desto weniger ist Markdown ausreichend.
Wie hoch ist die Release-Frequenz?
Bei wöchentlichen Releases lohnt sich die Investition in Toolchain-Disziplin schneller als bei jährlichen.
Wie eng ist die Bindung an die Engineering-Pipeline?
Pull-Requests gegen Dokumentation in derselben Codebase sprechen für Markdown.
Welche Tooling-Reife hat das Team?
DITA verlangt erfahrene technische Redakteure mit XML-Stack-Kenntnissen; die gebotene Modularität steigert eben auch die Komplexität des Content Tools. Markdown läuft mit jedem Engineering-Team.
Welche KI-Integration ist geplant?
Wer RAG, Embedding-Suche oder Dokumentationsagenten plant, sollte den Übergang zu Markdown-Output explizit mitdenken. Hybride Pipelines machen das möglich.
Eine englische Fassung dieses Artikels findet sich unter DITA and Markdown.
Fazit
DITA und Markdown sind keine konkurrierenden Lager, sondern Werkzeuge für unterschiedliche Anforderungsprofile. Wer Mehrsprachigkeit, Varianten und Compliance tragen muss, kommt an strukturiertem Content selten vorbei. Wer schnell schreiben und mit KI-Pipelines integrieren will, beginnt mit Markdown. Hybride Pipelines verbinden beide Welten, ohne dass sich Teams auf eine Doktrin festlegen müssen.
EverBright IT berät Unternehmen bei der Tool-Wahl und beim Aufbau hybrider Doku-Pipelines mit Anbindung an KI-Systeme. Mehr zu unserer Software-Engineering-Beratung oder direkt Kontakt aufnehmen.
Häufige Fragen
Was unterscheidet DITA von gewöhnlichem XML?
DITA ist ein semantischer XML-Standard mit festen Inhaltstypen wie Topic, Concept, Task und Reference. Gewöhnliches XML ist nur eine Syntax. DITA ergänzt Schema, Filter-Mechanismen, Wiederverwendung über Maps und ein etabliertes Ökosystem aus Editoren, Validierungen und Render-Pipelines. Wer XML schreibt, schreibt Struktur. Wer DITA schreibt, folgt in seiner Struktur einer Branchen-Konvention.
Lohnt sich DITA für ein Software-Startup?
In den meisten Fällen nein. Startups profitieren von schneller Iteration, Markdown reicht. Sobald aber Mehrsprachigkeit, Compliance-Anforderungen oder Variantenpflege ins Spiel kommen, kann der Wechsel sinnvoll werden. Die Migration aus Markdown nach DITA ist mit guten Toolchains in Wochen statt Monaten machbar.
Kann man DITA mit RAG-Systemen kombinieren?
Ja, aber meistens über einen Rendering-Schritt. DITA-Inhalte werden in eine flachere Struktur überführt, etwa Markdown oder reines Text-XML, das die Embedding-Pipeline verarbeiten kann. Direkte Embeddings auf DITA-XML sind technisch möglich, liefern aber häufig schlechtere semantische Ähnlichkeitsergebnisse als die gerenderten Inhalte.
Welche Tools unterstützen DITA in der Praxis?
Etablierte Editoren sind Oxygen XML Editor, FrameMaker und MadCap Flare. Open-Source-Pipelines laufen über DITA Open Toolkit für die Render-Schritte. Wer hybride Pipelines aufbaut, kombiniert diese Tools mit Markdown-Editoren und CI-Skripten, die zwischen den Formaten konvertieren. Die Werkzeuglandschaft ist reif, aber nicht kostenfrei.
