Is a publishing SDK only for DITA?

No. Pipelines exist for DocBook, other XML vocabularies, Markdown and proprietary formats; DITA is a common, well-documented example.

Why validate before transforming?

Invalid markup can produce incomplete or silently wrong output. Validation stops the build where the error is.

All context cards

Context card

Stages of a publishing pipeline

What happens to structured content inside a publishing SDK?

By knowledge.aitechdoc.world

Reviewed 29 September 2026

Review log and changes

The short answer

A publishing SDK runs structured source content through a fixed sequence of stages: it resolves the map and its references, validates the markup, applies filtering for the intended audience or product variant, transforms the result into an output format and packages it with its metadata. Each stage can be configured or extended, so one source yields many outputs.

For: Technical writers and information architects working with structured content

Key points

Resolve: maps, keys and content references are expanded into one document set.
Validate: the markup is checked against its schema before anything is produced.
Filter: conditional content is kept or removed for a product, audience or platform.
Transform: XSLT or similar processing produces HTML, PDF, help formats or data packages.
Package: outputs carry metadata so delivery systems can find and filter them.

The context

From source to deliverable

In a DITA-based toolchain a DITA map collects topics. The publishing SDK first resolves the map: keys are bound, content references are pulled in. Then the result is checked by schema validation.

Conditional processing removes or keeps content for the variant being built. Transformation — typically XSLT — produces the output formats, and packaging adds the metadata that portals and content delivery systems use for search and filtering.

Where the SDK is extended

Plug-ins add output formats, change styling or insert processing steps. Documenting these extensions matters as much as documenting the content: an output depends on both.

See the encyclopedia article Publishing SDKs.

Questions readers ask next

Is a publishing SDK only for DITA?: No. Pipelines exist for DocBook, other XML vocabularies, Markdown and proprietary formats; DITA is a common, well-documented example.
Why validate before transforming?: Invalid markup can produce incomplete or silently wrong output. Validation stops the build where the error is.

Sources

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

Review log and changes

Every context card is checked against its sources before it is published, and again whenever it changes; the date under the byline is the last review. Corrections (something was wrong) and additions (something was missing) are logged below with date and time (Berlin time). Typos, formatting and link fixes are not listed.

Reviewed 29 September 2026

No corrections or additions since publication.

Glossary terms on this card

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
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
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.