Semantics in steps

The steps of a procedure are defined in a task topic. Task topics typically have a simple structure of a single set of steps, but some procedures may require a more sophisticated structure that includes substeps and decision points.

Of the three original base information types in DITA, the task type is the most strongly typed. In other words, the task information type has the strictest rules. A task must be made up of one set of steps only. If you feel you need more than one set of steps, you almost certainly need to create more than one task topic.

In most cases, a set of steps is made up of one or more step elements, with each step element comprising a mandatory command (cmd) element, and an optional stepresult element.

The syntax of a typical set of steps is as in the following example:
    <cmd>Turn the key to the right.<cmd>
    <stepresult>The engine light will illuminate.</stepresult>
    <cmd>Press the <uicontrol>Start</uicontrol> button.</cmd>
In some cases, the complexity of a set of steps requires a more complex structure. Three more sophisticated elements can be used in such cases:

Examples are often a good way of explaining a task, and the task information type allows one (optional) example of a step to be included (stepxmp) after any cmd element, and for one (optional) overall example to be included after the steps block.

Explanatory information to support a command can optionally be added after the cmd within a step through the info element.

Before the steps block, the context in which a task is performed can be described through a context element. If there are any pre-requisites or pre-conditions for a task to be performed, these can be described in the prereq element above the steps block.

After the steps block, any post-requisites can be described (using the postreq element), and the overall result of the task steps can be described in a result element.

The overall structure of a task topic is: