S1000D vs DITA: Which Standard Fits Your Technical Documentation?

If you are setting up a structured technical publishing program, one of the first questions is which XML standard to use. For many teams it comes down to two: S1000D and DITA. They solve similar problems in different ways, and on many projects a contract or a customer has already made the choice.

Here is how each one works, where ATA iSpec 2200 fits, and how to decide. If structured authoring is new to you, start with our guide to structured authoring and component content management.

The short answer

If a defence or aerospace contract specifies S1000D, use S1000D. It is built for complex products with long service lives, where every piece of maintenance information has to be identified, controlled and tied to the configurations it applies to.

If you document software, hardware products or processes, and nobody has mandated a standard, DITA usually fits better. It is general purpose, topic based and supported by many authoring and publishing tools.

What S1000D is

S1000D describes itself as the “International specification for technical publications using a common source database”. It is produced by three industry bodies: ASD (the Aerospace, Security and Defence Industries Association of Europe), AIA (the Aerospace Industries Association of America) and the ATA e-Business Program of Airlines for America (A4A). It is free to download from s1000d.org.

It started in the early 1980s as an aerospace standard within ASD, then known as AECMA. At the time, civil airline projects were mostly documented to ATA 100 and military projects to various national specifications, so a working group set out to harmonise civil and military documentation, using ATA 100 as a source. Today s1000d.org lists its uses as defence systems on land, at sea and in the air, civil aviation, construction and ship industry products. The S1000D Steering Committee maintains it.

Data modules. The basic unit is the data module: a stand-alone unit of descriptive, procedural or operational information about a platform, system or component. Each one has an identification and status section, used to manage it in the database, control its applicability and run quality assurance, and a content section that holds the information itself.

Data module codes. Every data module is identified by its data module code (DMC). In the XML, the code is a set of attributes. Here is one for a made-up product:

<dmCode modelIdentCode="EXAMPLE" systemDiffCode="A"
        systemCode="32" subSystemCode="1" subSubSystemCode="0"
        assyCode="00" disassyCode="00" disassyCodeVariant="A"
        infoCode="520" infoCodeVariant="A" itemLocationCode="A"/>

Together they record which product the module belongs to, where it sits in the product’s structure and what kind of information it holds. All eleven of these attributes are required in the Issue 7 schema.

The CSDB. Data modules live in a common source database (CSDB). S1000D requires one to hold and manage the data modules a program produces, but it does not define how the CSDB should work. That is left to the tools.

Applicability. One data module can apply to some configurations of a product and not others. The <applic> element records this, pairing human-readable display text with assertions about product attributes or conditions that software can test. A viewer or publishing process can then show each reader only what applies to their product.

Publication modules. A publication is assembled by a publication module, which lists the data modules and other publications that make it up, grouped into ordered entries. The same data module can appear in many publications without being copied.

The current issue. The current issue is Issue 7. Its schemas on s1000d.org carry an issue date of 16 July 2026, and Issue 6 is dated 19 June 2024. Under s1000d.org’s numbering rules, a change to the first digit is a major revision that is not backward compatible, so moving a project from Issue 6 to Issue 7 will need some human intervention. Check which issue your contract or project business rules name before you start.

What DITA is

DITA, the Darwin Information Typing Architecture, is an OASIS standard. The OASIS DITA Technical Committee maintains it, with a remit to promote the architecture “for creating standard information types and domain-specific markup vocabularies”. OASIS members first approved it as a standard in 2005.

Topic types. Content is written as topics, each typed by the kind of information it holds. The core types are concept, task and reference. DITA 1.3’s technical content package adds general task, machinery task, troubleshooting and glossary entry topics, among others.

Maps. A DITA map organises topics into a deliverable, such as a manual, a help system or a website, and sets their order and hierarchy with <topicref> elements. Because the map supplies the context, the topics themselves can be reused in other maps.

Specialisation. You can define new element and topic types derived from existing ones. A specialised type inherits the meaning and default processing of its ancestor, so standard tools still handle it. The task topic is itself a specialisation of the base topic.

Conref reuse. The @conref attribute pulls in content from another element by reference. When an element uses @conref, its own content is ignored and replaced by the target’s:

<!-- In warnings.dita, inside the topic with id="warnings" -->
<note id="power-off" type="warning">Isolate electrical power
before removing the cover.</note>

<!-- In any other topic: reuse it by reference -->
<note conref="warnings.dita#warnings/power-off"/>

DITA also has conditional processing attributes for filtering content by audience, product or platform when you publish.

The current version. DITA 1.3 is the current OASIS Standard, approved on 17 December 2015, with Errata 02 approved in June 2018. The committee is developing DITA 2.0 in its GitHub repository. As at October 2026, OASIS has not published DITA 2.0 as a standard, so DITA 1.3 remains the approved version.

S1000D and DITA side by side

	S1000D	DITA
Maintained by	ASD, AIA and A4A’s ATA e-Business Program	OASIS DITA Technical Committee
Origins	Aerospace standard, early 1980s	OASIS Standard since 2005
Unit of content	Data module	Topic
Identifier	Data module code	File name, IDs and keys
Building a publication	Publication module	Map
Variants	Applicability (<applic>)	Conditional processing attributes
Tailoring	Project business rules	Specialisation
Repository	A CSDB, required but not defined	Your choice, often a CCMS
Current version	Issue 7, dated 16 July 2026	DITA 1.3; 2.0 in development
Typical use	Defence systems, civil aviation, construction, ships	Software, product and process documentation

Where ATA iSpec 2200 fits

Search for S1000D and you will soon meet ATA iSpec 2200. The ATA e-Business Program describes it as a global aviation industry standard for the content, structure and electronic exchange of aircraft engineering and maintenance information from manufacturer to operator. It is a suite of data specifications for maintenance requirements and procedures and aircraft configuration control, including SGML DTDs, and it includes the ATA Standard Numbering System that gives aircraft systems their chapter numbers.

The two are related rather than rivals. The ATA e-Business Program publishes both. Its Technical Data Working Group maintains iSpec 2200 and also represents civil aviation in S1000D, and for civil aviation projects that use S1000D it publishes Spec 1000BR, the civil aviation business rules for S1000D.

So “S1000D vs iSpec 2200” is rarely a free choice. Civil aviation maintenance data follows what the manufacturer delivers and what operators need. If you work with commercial aircraft data, find out which standard your sources use before you design anything.

When each one fits

S1000D fits when:

• a defence or aerospace contract, or your customer, specifies it
• the product is complex and long-lived, and maintenance information must be identified and controlled module by module
• the same information applies differently to different configurations or modifications, and readers should only see what applies to them
• you exchange data with partners who also work in S1000D

DITA fits when:

• you document software, hardware products or business processes, and nobody has mandated a standard
• your content splits naturally into concept, task and reference topics
• you reuse content across products and publish to several formats
• you want a wide choice of authoring and publishing tools

What about DITA vs Markdown? In our view, Markdown in version control is often enough for developer documentation that lives next to the code and has little reuse. DITA earns its place when typed topics, reuse and filtering across many outputs matter.

Tooling: a CCMS for DITA, a CSDB for S1000D

DITA content usually lives in a component content management system (CCMS), which stores topics and maps, tracks versions, runs review and publishes. Our CCMS guide explains what a CCMS does and compares the main products.

S1000D content lives in a CSDB. Because the specification requires a CSDB but leaves its functionality open, CSDB products can differ in how they handle data module codes, issue and status, applicability and publication modules. When you assess one, test it with your own data modules and business rules, on the S1000D issue your contract names.

Some platforms handle both. Quark says Quark Publishing Platform (QPP) lets you use any XML schema, naming Quark Smart Content, DITA, DocBook and S1000D, and that “you can even convert your content from one schema to another in QPP.”

We are a Quark and QPP partner for Australia and the USA. We sell QPP licences, implement it and support it. The Australian Energy Market Commission’s regulatory publishing runs on QPP, which we implemented. We also built a custom QPP NextGen extension for legislative agencies and legislative bodies that brings Git-style branching to document management. There is more on that under regulatory and legislative publishing.

Converting between S1000D and DITA

Moving content between the two is a transformation, not a file conversion. The structures only partly line up:

• A DITA topic is roughly the counterpart of a data module, and a map of a publication module.
• DITA has no data module code. Each topic needs one, assigned from an agreed breakdown of the product, before it can live in a CSDB.
• S1000D applicability has to become DITA conditional attributes going one way, and DITA conditions have to become applicability assertions going the other.
• The S1000D identification and status section, which manages a data module in the CSDB, its applicability and its quality assurance, only partly maps to the metadata in a DITA topic’s prolog.

Write the mapping down first and test it on real content. We migrate in stages: document the current estate, plan the migration, pilot on documents you nominate, test and run UAT, then migrate systematically. We carry existing identifiers and version history across rather than resetting everything to version one.

Our team works across S1000D (including applicability, across multiple issues), ATA iSpec 2200, DITA and DocBook. Where clients need to move between formats, we build transposition rather than forcing a single-standard decision.

Where to start

Start with the requirement, not the tool. If a contract names S1000D, find out which issue and which business rules apply. If nobody has mandated a standard, model a sample of your content as DITA topics and see whether the types fit.

Once publications are released, they also need to reach the right readers. Our Content Portal delivers version-critical documents with SSO, role-based access and watermarking. For the wider picture, see our technical publications practice and our Quark Publishing Platform page.

This guide is written for Australian organisations. In the USA, start with Shakewell LLC at shakewellusa.com.

---

Sources: S1000D, Getting Started, S1000D Downloads, Issue 7 description, Issue 7 descriptive schema, Issue 7 publication module schema and Issue 6 descriptive schema (ASD, AIA, A4A), OASIS DITA TC, DITA Version 1.3 Errata 02, DITA Version 1.3 Part 3: All-Inclusive Edition, Members Approve DITA as OASIS Standard and DITA TC GitHub repository (OASIS), ATA e-Business Program and Standards (ATA e-Business Program, Airlines for America), and Quark Publishing Platform (Quark).