AUTHOR·VALIDATE·BUILD·PUBLISH

One source. Every output channel.

One repository of DITA-authored topics. One DITA-OT build pipeline triggered on every merge. Six outputs — print PDF, responsive HTML5, EPUB3, IETM, SCORM, and RAG-grounded retrieval — emitted from the same source, validated by the same schema, localized through the same translation memory.

Solutions
  1. Technical Docs & Publishing
  2. Content Migration
  3. XML Data Interoperability
  4. AI-Ready Content

What unstructured publishing costs.

Hand-authored, single-format documentation has three compounding failure modes. Each one gets worse with every product release, every new market, every added language.

  1. Authored five times, owned once.

    The same warning paragraph lives in the Word doc, the PDF, the help center, the slide deck, and the eLearning module. Five edits per change. Four of them get skipped — and the next auditor reads one of the four stale copies.

  2. Translation pays for redundancy.

    A 200-page manual with 35% reused content gets translated as if every page were unique. The same sentence pays for translation twelve times across the product line, and the inconsistencies between independent translators become the next compliance risk.

  3. Layout is a manual step.

    Page breaks, figure placement, running headers, change bars — every release, by hand, in InDesign or FrameMaker, by someone whose actual job is writing. The bottleneck isn't authoring. It's the four-day formatting cycle that follows it.

The pipeline

The output is a build artifact, not a deliverable.

Every output starts as a .dita topic in a CCMS or a git-tracked DITA project. Topics are validated against DITA 1.3 plus project-specific Schematron rules on every commit. Builds run inside DITA-OT — Apache FOP or Antenna House XSL Formatter for print PDF, the html5 transtype for web, the epub3 transtype for offline reading, and project plugins for IETM, SCORM, and JSON retrieval. CI runs the build on every merge to main. No designer reformats anything. No writer “exports to PDF.”

  1. Author

    DITA 1.3 topics

    Authored in IXIASOFT, Heretto, Paligo, or Tridion Docs — or a git-tracked DITA project for engineering-led teams.

  2. Validate

    DITA 1.3 schema + Schematron

    Schema and Schematron rule sets run on every commit. The build fails on a schema error — invalid content never makes it to a transform.

  3. Transform

    DITA-OT 4.x

    Apache FOP or Antenna House XSL Formatter for print PDF. Built-in html5 and epub3 transtypes. Project plugins for IETM, SCORM, and JSON retrieval.

  4. Build

    GitHub Actions / Bamboo / Jenkins / GitLab CI

    Triggered on every merge to main. Outputs cached, versioned, and tagged as immutable build artifacts.

  5. Publish

    CDN, CCMS Dynamic Delivery, LMS, retrieval index

    Static deploy to Vercel, Netlify, or S3 + CloudFront. Dynamic delivery from the CCMS. SCORM upload to the LMS. JSON chunks to the RAG index.

Five outputs, one source.

Each is a transtype, a plugin, or a packaging step in the same DITA-OT build. None require a separate authoring tool, a separate review cycle, or a separate translation pass.

  1. Print PDF.

    Capability statements, parts catalogs, regulatory submissions.

    XSL-FO via Apache FOP or Antenna House XSL Formatter. Table of contents, index, list of figures, cross-references, and change bars driven by @rev attributes. Running headers and footers carry topic context across page breaks. Output stream-suitable for offset digital print, archival, and 21 CFR Part 11 regulated submissions.

    What does the regulatory team do with the four-day “PDF rebuild for the change-bar markup” cycle once it’s gone?

  2. Responsive HTML5.

    Documentation portals and product help.

    DITA-OT html5 transtype with a custom theme. Breadcrumb navigation derived from the DITA map hierarchy, full-text search via lunr or Algolia, and stable version-aware URLs for every topic. Static-host-deployable to Vercel, Netlify, or S3 + CloudFront — or served from the CCMS Dynamic Delivery layer.

    When the URL of every paragraph stays stable across releases, what stops being an emergency?

  3. EPUB3 + IETM.

    Offline reading and interactive procedures.

    Reflowable EPUB3 for training guides and operator handbooks. Interactive electronic technical manuals — S1000D-adjacent, procedural-map driven — for field service workflows. Both consume the same DITA topics: the IETM gets the procedural maps, the EPUB gets the reference content. Neither is re-authored.

    The technician in the bay and the trainee in the classroom were never reading different books — only different renders.

  4. SCORM eLearning.

    Courseware emitted from the same source.

    SCORM 1.2 and 2004 packages built directly from DITA learning content. Quizzes, assessments, and completion tracking emitted as part of the build. No duplicate authoring in a separate courseware tool, no parallel review cycle. LMS-portable through any Tin Can / xAPI endpoint.

    Why is the eLearning team writing the same procedure for the third time?

  5. In-app help, microcontent, RAG.

    The contextual surface, retrieval-grade.

    <shortdesc> and conkeyref-driven microcontent maps naturally to tooltips, empty-state hints, and walkthrough steps. The same DITA topics, chunked by element boundaries and tagged with audience metadata, serve as the retrieval corpus for RAG-grounded support chat — measured at 85% retrieval precision in life-sciences and financial-services pilots.

    The chatbot doesn’t need its own content. It needs your content, structured well enough to find the right paragraph.

Localization

Translate once. Render six times.

Translation memory operates at the segment level. When a DITA topic doesn’t change between releases, the TM matches it as a 100% segment, and the paragraph isn’t sent for translation again.

Reuse compounds the effect. A <warning> referenced across twelve manuals via conref is translated once; the translation is reused everywhere the reference resolves. A safety statement that ships in five output formats is translated once, not five times — the format-specific rendering happens after the localized DITA is built.

On a typical Extense engagement, translation cost drops 72% in the first localized release after migration. Most of that savings recovers before the second release ships, because every subsequent release only pays for the segments that actually changed.

Related

See CCMS & Publishing deliverables and standards

Sample Content Assessment

Send us a 20-page sample — DITA, Word, FrameMaker, unstructured XML, or PDF. We’ll return a conversion feasibility, content recovery rate, and pipeline-effort estimate within two business days.

Submit a sample →