Publishing SDK

Publishing SDKs sit at the output end of a structured-content workflow. Where a DITA map and its topics describe what the content is, the publishing SDK decides how that content becomes a deliverable: which processor runs, which stylesheets apply, which conditions are filtered out, and which files land in the output directory. The best-known open-source example is the DITA Open Toolkit, whose documentation describes transformations, plug-in installation, and extension mechanisms; commercial editors, CCMS products, and formatter engines ship comparable toolkits, often wrapping the same underlying transformation standards.

The category overlaps with the general notion of a software framework: a publishing SDK usually prescribes a build lifecycle and extension points into which authors and developers plug their own code, rather than offering a library that callers drive freely. The encyclopedia subject area places it as one of four SDK types — see publishing SDKs in the overview of software development kits.

How it applies

• Typical components. Transformation processors (XSLT engines, XSL-FO or CSS-based formatters, Markdown converters), stylesheet and template sets per output format, a plug-in framework with declared extension points, validation and preflight checks, and a command-line entry point for automation.
• Documentation work. Output customization is the daily contact surface: overriding stylesheets, adding branding, mapping metadata to cover pages and headers, and controlling conditional processing so that audience- or product-specific variants build from one source.
• Source-side dependencies. Publishing SDKs consume the resolution semantics of the authoring vocabulary — DITA maps, keys, and content references — so changes in the source model can silently change output. Document which resolution behavior your build relies on.
• Engineering work. Treat the toolkit like any other build dependency: pin its version, keep plug-ins in version control, and record the exact invocation. Plug-in APIs and stylesheet entry points are not covered by a single public specification, so upgrades can break customizations.
• Validation and quality gates. Schema validation of the source, link and key resolution checks, and log parsing for warnings belong in the pipeline. A clean build is evidence that the transformation ran as configured — nothing more.
• Compliance-relevant documentation. Where deliverables must meet format or accessibility requirements, the requirement applies to the output, which has to be tested on its own terms. Using a particular publishing SDK, stylesheet, or standard does not by itself make a deliverable conformant, accessible, or legally compliant.
• Interoperation with the other SDK types. A developer SDK may fetch content or push builds over a REST API; a platform SDK may embed publishing actions in an authoring tool's UI; delivery targets (device manuals, XR guidance) can come from hardware-side projects. The publishing SDK is the stage that turns one content set into several channel-specific outputs.

Publishing SDK vs. developer SDK

A developer SDK helps you call a service: it wraps an API, handles authentication, serializes requests, and is judged by its interface contract. A publishing SDK helps you transform documents: its inputs are content files and configuration, its outputs are deliverables, and its extension surface is stylesheets and plug-ins rather than client classes. Both may be shipped as libraries and both have versioned APIs, but the failure modes differ — a broken developer SDK call returns an error, a broken publishing customization produces a plausible-looking but wrong deliverable, which is why output review stays part of the process.

External references

• DITA Open Toolkit — installing plug-ins (developer reference)
• DITA Open Toolkit — current documentation
• OASIS DITA Version 1.3, All-Inclusive Edition
• W3C: XSL Transformations (XSLT) Version 3.0
• W3C news: XSLT 3.0 becomes a Recommendation (2017)