Explainer
The S1000D Process Data Module, Explained
The Idea
A Procedure That Can Decide
A normal procedural data module is linear: preliminary requirements, steps, close-up. Real maintenance often is not. A fault isolation task depends on what the technician finds; an adjustment repeats until a reading is in tolerance. The process data module scripts that kind of flow. It sequences data modules and steps, branches on conditions, loops, keeps variables, asks the technician for input, and can hand off to an external application and act on what it returns.
It only makes sense where something can run it: an interactive viewer that evaluates the logic as the technician works. That makes it a feature of interactive electronic publications, and one of the clearest differences between an IETM and a PDF on a screen.
The Parts
How the Script Is Built
Inside the process element, a flow runs from optional variable declarations and preliminary requirements, through the sequence, to optional close-up requirements. These are the building blocks, named as the schema names them:
- dmSeq
- The flow itself: a sequence of nodes, alternatives, conditions, and loops.
- dmNode
- One screen: a reference to a data module, or steps and content with a dialog, or a call to an external application.
- dmIf
- A decision: an expression, then the sequence to follow when it is true (dmThenSeq), and optionally the one when it is false (dmElseSeq).
- dmLoop
- Repetition while an expression holds, with an optional assertion to check afterward.
- variableDeclarations
- The variables the flow uses, which nodes can set and expressions can test.
- dialog
- Interaction with the technician: user entries, menus, push buttons, and messages.
Where It Fits
Before You Write One
Process data modules are powerful and demanding. Whether a program uses them, what its viewer must support, and how the logic is tested are business rules decisions to settle before authoring, not after. The Issue 7 release announcement lists corrections for the process data module among its changes, so programs moving issues should check theirs. For the other data module types and when each applies, see our tour.
FAQ
Questions We Hear
What is a process data module in S1000D?
A data module that scripts a procedural flow. In the specification's words it represents a procedural flow consisting of several data modules and/or steps that are sequenced, with decision points, looping, and selective filtering supported, and an interface to external applications that can return results to direct the flow.
When would a program use a process data module?
When a procedure is not one straight line: fault isolation that branches on what the technician observes, a check that repeats until a reading is in tolerance, or a task that calls a diagnostic application and continues based on its result. It is written for interactive delivery, where a viewer can run the logic.
Does a process data module work in a PDF?
Not as intended. Its value is the logic, which needs an interactive viewer to evaluate expressions, track variables, and present dialogs. A page-based rendering can show the steps but not run the flow, which is why process data modules belong to programs delivering interactive electronic publications.
Get In Touch
Scripting Interactive Procedures?
Process data modules pay off when they are designed with the viewer and the business rules in mind. We help programs decide where they are worth it and build them properly.