Explainer
An S1000D Data Module, Line by Line
The Module
A Descriptive Module, Nearly Whole
This is the drivetrain description from the official Bike sample that ships with the specification, at Issue 4.2 (the newest Bike set publicly available). Its data module code is DMC-S1000DBIKE-AAA-DA4-00-00-00AA-041A-A, which our DMC decoder will break down for you. It is trimmed for reading: long passages are elided and marked, and a few optional status elements (the technical standard, skill level, and reason for update) and attributes are omitted. Everything shown is as published.
<?xml version="1.0" encoding="utf-8"?>
<dmodule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.s1000d.org/S1000D_4-2/xml_schema_flat/descript.xsd">
<identAndStatusSection>
<dmAddress>
<dmIdent>
<dmCode modelIdentCode="S1000DBIKE" systemDiffCode="AAA"
systemCode="DA4" subSystemCode="0" subSubSystemCode="0" assyCode="00"
disassyCode="00" disassyCodeVariant="AA"
infoCode="041" infoCodeVariant="A" itemLocationCode="A"/>
<language countryIsoCode="US" languageIsoCode="en"/>
<issueInfo issueNumber="008" inWork="00"/>
</dmIdent>
<dmAddressItems>
<issueDate day="31" month="12" year="2016"/>
<dmTitle>
<techName>Drivetrain</techName>
<infoName>Description of how it is made</infoName>
</dmTitle>
</dmAddressItems>
</dmAddress>
<dmStatus issueType="changed">
<security securityClassification="01"/>
<dataRestrictions><!-- distribution, export control, copyright: elided --></dataRestrictions>
<responsiblePartnerCompany enterpriseCode="B6865">
<enterpriseName>AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE</enterpriseName>
</responsiblePartnerCompany>
<originator enterpriseCode="B6865">
<enterpriseName>AEROSPACE AND DEFENCE INDUSTRIES ASSOCIATION OF EUROPE</enterpriseName>
</originator>
<applicCrossRefTableRef><!-- points at the ACT, info code 00W --></applicCrossRefTableRef>
<applic>
<displayText>
<simplePara>Mountain bicycle and (Mountain storm Mk1 or Brook trekker Mk9)</simplePara>
</displayText>
<evaluate andOr="and"><!-- the same condition as logic: elided --></evaluate>
</applic>
<brexDmRef><!-- points at the project BREX, info code 022 --></brexDmRef>
<qualityAssurance>
<firstVerification verificationType="tabtop"/>
</qualityAssurance>
</dmStatus>
</identAndStatusSection>
<content>
<description>
<levelledPara>
<title>Drive train</title>
<para>The drive train is the group of components ... <!-- elided --></para>
</levelledPara>
</description>
</content>
</dmodule>Line by Line
What Each Part Does
- dmodule
- The root. The schema reference names the issue and the data module type: here Issue 4.2, descript.xsd, a descriptive module.
- identAndStatusSection
- Everything about the module rather than in it: who it is, and what state it is in. Every data module has one, whatever its type.
- dmCode
- The data module code as attributes: model, system difference code, the SNS (DA4-0-0-00, the drivetrain), disassembly code and variant, information code 041 with variant A, and item location A. Written out, it is DMC-S1000DBIKE-AAA-DA4-00-00-00AA-041A-A.
- language
- The language and country, as ISO codes. The same module in French is a different data module with the same code.
- issueInfo
- Issue 008, in-work 00. The first release is 001, each approved release increments it, and in-work 00 means released rather than a draft.
- dmAddressItems
- Supporting information that is not part of the identity: the issue date, and the title.
- dmTitle
- techName names the thing (Drivetrain); infoName names the kind of information, and is expected to match the information code's own name (041 is Description of how it is made).
- dmStatus
- The module's status. issueType="changed" means this issue carries marked changes; the other values include new, revised, deleted, and status.
- security
- The classification of the module and its illustrations. 01 is the lowest level, for example unclassified.
- responsiblePartnerCompany and originator
- Who is responsible for the module, and who produced it, by enterprise code and name.
- applicCrossRefTableRef and applic
- Applicability: a pointer to the project's applicability cross-reference table, then the condition this module applies under, both as display text for people and as logic for software.
- brexDmRef
- The business rules this module must satisfy, by reference to the project's BREX data module (information code 022).
- qualityAssurance
- Verification status: unverified, or verified once or twice. tabtop means it was verified at a desk.
- content
- The information itself. A descriptive module uses description and levelledPara, headed paragraphs that nest; a procedural module would use procedure, with preliminary requirements, the main procedure's steps, and close-up requirements.
The Pattern
What to Take From It
Most of this module is not content. It is identity and status: the code that addresses it, the issue that versions it, the applicability that says where it is true, the BREX that governs it, and the verification that says someone checked it. That proportion is the point of S1000D. It is what lets a CSDB manage thousands of modules, a publication pull the right ones, and a viewer show a maintainer only what applies to the aircraft in front of them.
Each of those parts has a fuller explainer: the data module code, the SNS, the information codes, applicability, the BREX, and the data module types that decide what goes in the content section.
FAQ
Questions We Hear
Where can I get real S1000D example data?
From the official specification package, free to download from the S1000D site. Recent packages include the Bike sample data set: a complete, small project of data modules, publication modules, illustrations, and its own BREX. It is a teaching set, not an official conformance test suite.
What does an S1000D data module look like?
An XML file with two parts. The identification and status section says what the module is (its data module code, language, and issue) and what state it is in (security, responsibility, applicability, the governing BREX, and quality assurance). The content section holds the information, structured according to the data module type: description, procedure, fault isolation, parts data, and so on.
Is there an S1000D template?
The specification's schemas define the structure, and tools generate a valid skeleton from them; the open-source s1kd-tools, for example, create new data modules from the command line. The Bike sample is the best set of worked examples. A program's own templates should come from its business rules, which decide which of the specification's options it uses.
Does this example apply to Issue 6 and Issue 7?
The overall shape does: every issue since 4.0 has the identification and status section followed by content, and the same data module code attributes. The detail changes between issues, so the schema of the issue your program uses is the authority. The public Bike sample shown here is from Issue 4.2.
Get In Touch
Writing Your First Modules?
Our S1000D course has your team reading and writing real data modules against your own business rules, and our coaching stays with them through the first ones that ship.