S1000D

S1000D grew out of work in European aerospace industry bodies in the early 1980s, building on the earlier ATA chapter-based approach to aircraft documentation; the first issue was signed and released in 1989. Later issues widened the scope from air vehicles to land and sea products and to publications that do not document equipment at all. The specification is published by the S1000D Council and Steering Committee, formed by ASD, AIA, and the ATA e-Business Program, and the specification document, XML schema package, data dictionary, default BREX, business rules template, and the "Bike" sample data set are offered as free downloads from the official user site. Issue 6 is the latest released issue announced on the official pages; because issue and bug-fix release dates are published per issue, they should be verified on the official site before being quoted in a contract or a style guide.

The specification is organized around a few load-bearing ideas. A data module is the smallest self-contained information unit; its data module code (DMC) encodes the product, the system breakdown position (via a standard numbering system, SNS), the type of information (information code), and the item location, so that a module can be addressed without reference to a book or a page number. A publication module (PM) describes how modules are assembled for a deliverable; illustration control numbers (ICN) identify graphics; common information repositories (CIR) hold shared data such as parts or tools; applicability statements bind content to product variants and configurations; and the CSDB holds all of these objects with their status information. S1000D states that there must be such a database but does not prescribe the functionality of the software that implements it, which is why implementations differ widely between programs.

Because the specification is deliberately broad, a program has to narrow it. Business rules fix which schemas, codes, repositories, metadata values, and workflows apply; the business rules decision points (BRDP) in the specification act as the checklist, and a BREX data module makes a subset of those rules testable against the delivered XML. Naming S1000D in a contract therefore says little on its own — the business rules set is what makes two deliveries comparable, and conformance to them is never by itself evidence that a publication satisfies regulatory requirements for information for use or instructions for use.

How it applies

• Agree business rules before authoring. Decide the issue to be used, the schemas in scope, the SNS, the information codes, the applicability model, the graphics formats, and the delivery packaging, and write them down; retrofitting these decisions into an existing CSDB is expensive.
• Treat the DMC as an identifier, not a filename. Reporting, reuse, change management, and delivery acceptance all key off the data module code and its issue information, so coding discipline matters more than folder structure.
• Automate the checks. Validate instances against the S1000D schema package and against the project BREX; many teams add further rule sets, comparable in intent to Schematron checks in other XML stacks. Schema validation catches structure, not correctness of engineering content.
• Plan the output channels. The same CSDB content is published to page-oriented output and to interactive electronic technical publications; media, applicability filtering, and link resolution behave differently in each, so output requirements belong in the business rules.
• Expect integration with other S-Series specifications. S1000D is used alongside the ASD/AIA S-Series suite for logistic support analysis, provisioning, maintenance planning, in-service feedback, and training, so identifiers and breakdown structures should be aligned across those data exchanges.
• In machinery and software documentation, borrow the ideas selectively. Outside aerospace and defense, projects often adopt modular units, applicability, and single-source publishing but choose a lighter stack; S1000D pays off where a customer mandates it or where fleets, configurations, and long service lives make module-level change control necessary.
• Combine with controlled language. S1000D content is frequently written in a controlled English such as ASD-STE100 Simplified Technical English, which constrains wording while S1000D constrains structure.

S1000D vs. DITA

Both are XML approaches to structured authoring with reusable units, but their centers of gravity differ. DITA is an OASIS standard organized around typed topics, maps, keys, and specialization, and it leaves product identification and delivery logistics to the implementer. S1000D is an industry specification organized around data modules whose codes encode the product breakdown, plus a managed CSDB, applicability, business rules, and defined exchange packages for customer delivery. In practice, DITA is often chosen where authoring flexibility and software documentation dominate, S1000D where a contractual data exchange across a product's service life dominates; some programs run both and convert between them, which requires mapping identifiers, metadata, and applicability rather than only element names.

External references

• About S1000D (S-Series specifications portal)
• S1000D official site — About S1000D
• S1000D downloads: specification, schemas, data dictionary, sample data sets
• ATA e-Business Program: S1000D — International Specification for Technical Publications