S1000D Introduction: What is S1000D?

A High-Level Introduction to the S1000D Specification for Authoring Technical Data

Those interested in this introduction to S1000D have most likely examined the official specification itself, as well as several other websites, message boards, and discussion threads…and are still looking to understand exactly what S1000D does and what problems it solves.

As a one sentence explanation, S1000D is a supported standard for authoring, storing, and publishing maintenance and operational information. Keeping with that thought, it’s helpful to think of S1000D along those three tracks:

  1. Data Production
  2. Data Storage
  3. Data Publication

Data Production

One of the first things that people discover when beginning the process of learning S1000D is that data is created and maintained in “chunks” (the official term is Data Module. A data module is a discrete piece of information that describes an operation or task. While this is not an entirely new paradigm in the technical documentation community, it is distinct from the traditional means of authoring documents (front to back with content divided into chapters) and the ideal way to achieve the “holy grail” of document authoring: Content Reuse.

Note: Data Modules are the official point of reuse. A data module may be used as much/often as necessary. For example, the same series of repair steps may appear in 14 job guides for a given aircraft. Instead of creating those steps each and every time, the steps are stored in a data module and referenced.

Content reuse leads to the other item that people almost immediately know (or quickly discover) when learning S1000D: When creating an S1000D data module, you are creating an XML (or SGML) document.

Note: Hopefully, your S1000D will be XML, but we understand there are some reasons (contract stipulations) to keep authoring in SGML…keep in mind, however, that SGML tools are extremely limited and the S1000D communities’ focus is on the XML track.

Data Modules

Data Modules are logical groupings of a single comprehensive idea, thought or task. A good explanatory example is a repair manual for a truck, piece of machinery, ship, or aircraft. After introductory material, most manuals consist of chapters that contain tasks, with the tasks containing steps. In an S1000D environment, these tasks would be data modules.Additionally, if analysis warranted, the steps themselves could be data modules.

The unofficial rule of thumb when creating a data module (or any reusable chunk for that matter) is to create a chunk of data that is refined to its lowest point of reusability. That is, you want the data module to be small enough to be reused as many times as possible, but not so small that reusing it is not worth the effort. The process of determining the appropriate level of reuse is critical to your project’s success.

Guideline: Using the previous thought, a chapter of a manual is most likely too large to serve as an effective data module. Likewise a couple of sentences or a paragraph is too small. Again, a logical grouping of content, such as a task that contains a start and end, will probably serve as an effective data module.

Types of Data Modules

  • Procedural – Used to define a task, or more accurately, the steps for accomplishing a task.
  • Descriptive – Contains narrative information explaining the usage/concepts of a particular component.
  • Fault Isolation/Reporting – Used to provide guided troubleshooting.
  • Maintenance Planning – Scheduled maintenance/workcards.
  • Crew/Operator Information – Operation and/or emergency procedures.
  • Illustrated Parts Data – Rules for the publication of spare parts information.
  • Damage Assessment and Repair – Battle damage repair procedures.
  • Wiring Data – Wiring data descriptions.

Content of a Data Module

Identification Section. The identification section contains metadata that identifies the data module (so that it can be relocated, reused, etc.). This section contains information such as the Data Module Code, title, issue number, issue date, language as well as status information such as security, originator, applicability, QA status, etc.

Content Section. This, of course, is the primary focus of the data module. As stated in the specification, it contains the text and illustrations that are presented to the user. Rules for what both the Identification and Content Section can contain are controlled via an XML Schema or XML (or SGML) DTD.

Authoring Data Modules

To create a data module and the content within you need a couple of things. First, you need the appropriate XML Schema or DTD. Secondly, you need an editor capable of enforcing the rules contained inside of the XML Schema or DTD.

Naming Data Modules

“Naming” might be a bit of a misnomer. What is certain is that every Data Module has a Data Module Code. The DMC is a numbering system created exclusively by the S1000D Consortium to standardize the numbering of technical publications. While DMCs share a number of concepts similar to other numbering schemes (military, civil aviation), they incorporate additional features used to support modular (chunks) documentation.

Data Storage

The data base that contains all S1000D Data Modules is called the Common Source Data Base (CSDB). The purpose of the CSDB is to manage the data modules so that information is not duplicated, link relationships are maintained, and version control is applied to content.

Data Publication

There is no single means of publishing S1000D content. The publishing of S1000D begins by assembling the necessary data modules. This assembly of data modules is done via a Publication Module. Data Modules can contain references to data modules, other publication modules or even legacy content. Data Modules can be published to both paper and electronic formats.