2.2.2.4 Task topic (strict task)

The strict task document type supports the development of instructions for the completion of a procedure. The strict task document type is built using the general task information type combined with the Strict Taskbody Constraint. See the reference below to ensure that you have the correct task document type when you update to DITA 1.2.

The purpose of the standard task information type

Tasks are the essential building blocks to provide procedural information. A task information type answers the "How do I?" question by providing precise step-by-step instructions detailing the requirements that must be fulfilled, the actions that must be performed, and the order in which the actions must be performed. The task topic includes sections for describing the context, prerequisites, expected results, and other aspects of a task.

The structure of the task topic

The <task> element is the top-level element for the strict task topic. The strict task document type contains a title and a taskbody with optional alternative titles (titlealts), a short description or abstract, a prolog,and related-links.

The <taskbody> element is the main body element inside a strict task document type. The strict task body has a constrained structure, with these optional elements in the following order:

<prereq>
Describes information that the user needs to know or do before starting the immediate task. This section may occur only once.
<context>
Provides background information for the task. This information helps the users understand the purpose of the task and what they will gain by completing the task correctly. This section should be brief and does not replace or recreate a concept topic on the same subject, although the context section may include some conceptual information. This section may occur only once.
<steps>
Provides the main content of the task topic. A task consists of a series of steps that accomplish the task. The <steps> element must have one or more <step> elements, which provide the specifics about each step in the task. The <steps> element may occur only once.

The <step> element represents an action that a user must follow to accomplish a task. Each step in a task must contain a command <cmd> element which describes the particular action the user must perform to accomplish the overall task. The step element may also contain information <info>, substeps <substeps>, tutorial information <tutorialinfo>, a step example <stepxmp>, choices <choices>, or a stepresult <stepresult>, although these are optional.

<steps-unordered>
Provides alternative content for the task topic, allowing for a single step in a procedure or a set of commands that need not be performed in a specific order.
<result>
Describes the expected outcome for the task as a whole.
<example>
Provides an example that illustrates or supports the task.
<postreq>
Describes steps or tasks that the user should do after the successful completion of the current task. It is often supported by links to the next task or tasks in the <related-links> section.
Here is an example of a task topic:
<task id="birdhousebuilding">
    <title>Building a bird house</title>
    <shortdesc>Building a birdhouse is a perfect activity 
    for adults to share with their children or grandchildren. 
    It can be used to teach about birds, as well as the proper use of tools.
    </shortdesc>
 <taskbody>
  <context>Birdhouses provide safe locations for birds to build nests and raise their young. They also provide shelter during cold and rainy spells.</context>
  <prereq>To build a sound birdhouse, you will need a complete set of tools:
  <ul><li>hand saw</li>
      <li>hammer ... </li>
  </ul></prereq>
 <steps>
   <step><cmd>Lay out the dimensions for the birdhouse elements.</cmd></step>
   <step><cmd>Cut the elements to size.</cmd></step>
   <step><cmd>Drill a 1 1/2" diameter hole for the bird entrance on the front.</cmd>
         <info>You need to look at the drawing for the correct placement of the 
               hole.</info></step>
   ...
  </steps>
  <result>You now have a beautiful new birdhouse!</result>
  <postreq>Now find a good place to mount it.</postreq>
 </taskbody>
</task>

Maintaining specializations using the strict task model

Organizations that have created specializations based on the DITA 1.0 and 1.1 strict task model should review the recommendations in Migrating from DITA 1.1 to 1.2 to maintain their specializations.

Modules

The following DITA modules are provided for the task topic.

Return to main page.

OASIS DITA Version 1.2 -- OASIS Standard, 1 December 2010
Copyright © OASIS Open 2005, 2010. All Rights Reserved.