Field Guide
Choosing S1000D Tools: Authoring, CSDB, Publishing, Viewer
The Four Jobs
One Standard, Four Layers
The toolchain splits cleanly. Authoring: a schema-aware editor where writers produce valid modules with the guardrails behind a usable surface — BREX enforced at the cursor, not discovered at check-in. The CSDB: the common source database whose real product is lifecycle — versions, variants, workflow, supplier exchange, and APIs every other layer leans on. Publishing: assembly of modules into page-oriented and interactive outputs, the rendering pipeline included. Viewing: the IETP viewer where applicability filtering, navigation, and process modules either work for a gloved hand on a flight line — or don't.
Suites cover all four; the standard's exchange model means you don't have to. Data modules are the currency, so mixed toolchains are normal — and often stronger than any single vendor's weakest layer.
The Method
Score the Layers Separately
The failure pattern is buying the demo: one layer — usually authoring or the viewer — shines, the bundle rides in on it, and the program spends years compensating for the layers nobody scored. The countermeasure is procedural. Evaluate the four jobs as four line items with their own criteria and their own testers: authors judge the editor against your BREX and CIR usage; data managers put the CSDB through a supplier round-trip and an export-everything drill; the publishing pipeline renders yoursample modules, not the vendor's bicycle; the viewer goes in front of an actual maintainer. And ask every vendor the exit question early — complete data out, with history, in standard form — because the answer prices the relationship.
Where does a demo-ready module set come from before you've bought an authoring tool? That's one of the quiet services of a well-run program start: a small representative sample authored early, precisely so tooling is evaluated against reality. We run these evaluations for programs without selling any of the four layers ourselves in the authoring chain — our product interest is downstream, in delivery — which is exactly the seat you want your advisor in.
FAQ
Questions We Hear
What are the four jobs in an S1000D toolchain?
Authoring — the schema-aware editor where writers produce valid data modules without hand-tagging XML. The CSDB — the common source database that stores, versions, and controls the modules and everything around them. Publishing — the pipeline that assembles modules into outputs: page-oriented PDF and interactive electronic publications. And viewing — the IETP viewer maintainers actually work in, with applicability filtering, navigation, and links resolved. Some suites do all four; treating that as a requirement rather than a convenience is how buyers end up with one strong layer and three weak ones.
What questions expose a weak authoring tool?
Ask to see a real author's screen, not a demo. Does the editor enforce your BREX during authoring, or only find violations at check-in? How does it handle CIR references and applicability annotation — first-class UI, or raw attribute editing? What does a writer see when validation fails — a schema error message, or a human explanation? And the killer: how long did the last comparable customer take to make a new author productive? The tool's job is putting the spec's discipline behind a usable surface; a demo of typing paragraphs proves nothing.
What actually matters in a CSDB?
Lifecycle behavior, not storage. How are versions, variants, and applicability managed together? What does the workflow engine enforce — real state transitions with permissions, or labels? How does content arrive from and return to suppliers and partners (data dispatch and receipt is where multinational programs bleed)? What are the APIs like, since every other layer integrates here? And exit: can you get your complete data out, with history, in standard form, the day you leave? A CSDB you cannot leave is a pricing strategy, not a product.
Do we have to buy everything from one vendor?
No, and the interfaces are the point of the standard: data modules are the exchange currency, so mixed toolchains are normal and often stronger — the best editor for your authors, the CSDB that fits your program scale, the viewer your customer mandates. The integration questions are real but answerable. What we recommend against is the inverse: choosing a whole suite because one layer demos beautifully, then living with the rest. Evaluate the four jobs separately, score them separately, and let the bundle earn its convenience discount honestly.
Get In Touch
Four Decisions, Scored Honestly
We structure S1000D tool evaluations — criteria, sample data, and the exit questions vendors hope you forget — without a horse in the authoring race.