Ist ein Publishing-SDK nur für DITA gedacht?

Nein. Pipelines gibt es für DocBook, andere XML-Vokabulare, Markdown und proprietäre Formate; DITA ist ein verbreitetes, gut dokumentiertes Beispiel.

Warum vor dem Transformieren validieren?

Ungültiges Markup kann unvollständige oder unbemerkt falsche Ausgaben erzeugen. Die Validierung stoppt den Build dort, wo der Fehler liegt.

Alle Context Cards

Context Card

Stufen einer Publishing-Pipeline

Was geschieht mit strukturiertem Content in einem Publishing-SDK?

Von knowledge.aitechdoc.world

Geprüft 29. September 2026

Prüfprotokoll und Änderungen

Die kurze Antwort

Ein Publishing-SDK führt strukturierten Quell-Content durch eine feste Folge von Stufen: Es löst die Map und ihre Verweise auf, validiert das Markup, filtert für die vorgesehene Zielgruppe oder Produktvariante, wandelt das Ergebnis in ein Ausgabeformat um und verpackt es mit seinen Metadaten. Jede Stufe lässt sich konfigurieren oder erweitern, sodass eine Quelle viele Ausgaben ergibt.

Für: Technische Redakteure und Informationsarchitekten, die mit strukturiertem Content arbeiten

Das Wichtigste

Auflösen: Maps, Keys und Content-Referenzen werden zu einem Dokumentbestand zusammengeführt.
Validieren: Das Markup wird gegen sein Schema geprüft, bevor etwas erzeugt wird.
Filtern: Bedingter Content bleibt für ein Produkt, eine Zielgruppe oder Plattform erhalten oder entfällt.
Transformieren: XSLT oder eine vergleichbare Verarbeitung erzeugt HTML, PDF, Hilfeformate oder Datenpakete.
Verpacken: Ausgaben tragen Metadaten, damit Auslieferungssysteme sie finden und filtern.

Der Zusammenhang

Von der Quelle zur Ausgabe

In einer DITA-Toolchain sammelt eine DITA-Map Topics. Das Publishing-SDK löst zuerst die Map auf: Keys werden gebunden, Content-Referenzen eingezogen. Dann prüft die Schemavalidierung das Ergebnis.

Bedingte Verarbeitung entfernt oder behält Content für die gebaute Variante. Die Transformation – meist XSLT – erzeugt die Ausgabeformate, und das Verpacken ergänzt die Metadaten, die Portale und Content-Delivery-Systeme für Suche und Filter nutzen.

Wo das SDK erweitert wird

Plug-ins ergänzen Ausgabeformate, ändern das Layout oder fügen Verarbeitungsschritte ein. Diese Erweiterungen zu dokumentieren ist so wichtig wie den Content: Eine Ausgabe hängt von beidem ab.

Siehe den Enzyklopädie-Artikel Publishing SDKs (auf Englisch).

Fragen, die sich daran anschließen

Ist ein Publishing-SDK nur für DITA gedacht?: Nein. Pipelines gibt es für DocBook, andere XML-Vokabulare, Markdown und proprietäre Formate; DITA ist ein verbreitetes, gut dokumentiertes Beispiel.
Warum vor dem Transformieren validieren?: Ungültiges Markup kann unvollständige oder unbemerkt falsche Ausgaben erzeugen. Die Validierung stoppt den Build dort, wo der Fehler liegt.

Quellen

DITA Open Toolkit documentation — DITA-OT project
XSL Transformations (XSLT) Version 3.0 — W3C, 8. Juni 2017

Prüfprotokoll und Änderungen

Jede Context Card wird vor der Veröffentlichung und bei jeder Änderung erneut anhand ihrer Quellen geprüft; das Datum unter der Autorenzeile ist die letzte Prüfung. Korrekturen (etwas war falsch) und Ergänzungen (etwas fehlte) stehen unten mit Datum und Uhrzeit (deutsche Zeit). Tippfehler, Formatierung und Link-Korrekturen werden nicht aufgeführt.

Geprüft 29. September 2026

Seit der Veröffentlichung keine Korrekturen oder Ergänzungen.

Glossarbegriffe dieser Card

Die Glossare erscheinen auf US-Englisch.

DITA (Darwin Information Typing Architecture)
DITA (Darwin Information Typing Architecture) is an OASIS XML standard for creating, managing and publishing topic-based content. Content is authored as typed topics, organized and reused through maps, and extended through specialization. DITA 1.3 is the version approved by OASIS in December 2015.
DITA map
In DITA, a map is a document that organizes topics and other resources into a structured collection — typically a deliverable such as a manual or help system. It defines the hierarchy and sequence of topics, their relationships and key definitions, and can contain other maps.
DITA topic
In DITA, a topic is a unit of information with a title and content that is short enough to be specific to a single subject and can be understood on its own. The generic topic type, <topic>, is the base from which all other DITA topic types are specialized.
DITA conditional processing
In DITA, conditional processing is the filtering or flagging of content based on the values of metadata attributes such as @audience, @platform, @product, @otherprops, @props and @deliveryTarget. The conditions to apply are specified at publishing time, usually in a DITAVAL file.
DITA content reference (conref)
In DITA, a content reference (conref) is a reuse mechanism in which an element, through the @conref attribute, pulls in the content of another element of the same type from another topic or map. When the document is processed, the referencing element is replaced by the referenced element.
DITA key
In DITA, a key is a name defined in a map (with the @keys attribute) that stands for a resource or a piece of text. Topics and maps refer to the key with @keyref instead of a direct address, and the map that is processed decides what the key resolves to.
Schema validation
Deutsch: Schemavalidierung
In data processing, schema validation is the automated check of a data document, such as XML, JSON or a configuration file, against a schema that defines its permitted structure, data types, values and required elements.
Metadata
Deutsch: Metadaten
In information management, metadata is data that describes other data or resources, such as their meaning, origin, format, units, owner, time stamp, version or classification, so that they can be found, understood, managed and used correctly.