More general task type.
The DITA task specialization specifies a rather restrictive content model. Substantial interest exists in specifiying a less restrictive container for task and task-like information. This proposal advocates the following approach:
Specify a less restrictive content model for <task> than the DITA 1.1 <task> content model.
Allow implementers the choice of adopting the DITA 1.2 <task> content model, or emulating the DITA 1.1 <task> content model through the DITA 1.2 constraint mechanism (proposal 12008).
The new <task> specialization must:
Allow adopters to use the new, less restrictive DITA 1.2 <task> specialization, or the legacy DITA 1.1 <task> specialization.
Allow authors to insert admonishments within a step before the user action.
Allow authors to semantically introduce, group, and explain sets of <step> elements within <steps>.
Allow adopters to express step-like items without the semantic constraints of <step>.
Allow adopters more flexibility in creating procedure-like constructions.
This proposal supports the following use cases:
Adopters in manufacturing have noted the lack of support for including an admonishment as a semantic part of a step but before the directive to the user. This can be particularly important when the user action may cause harm to equipment or injury to people. See http://www.oasis-open.org/apps/org/work.
Adopters that do not need the semantic distinctions provided by child elements of <step> are forced to use unnecessarily complex markup. In many implementations, the <cmd> element is used because it is required, not because it provides a necessary semantic distinction.
The <task> specialization does not support adopters that wish to render non-declarative or non-linear procedures (e.g., procedures with a single step and a figure, troubleshooting procedures that do not necessarily flow from one step to the next).
Adopters could choose between the DITA 1.2 and DITA 1.1 (constrained) <task> specializations, depending on requirements of the organization. Authors and adopters could choose between the two specializations depending on requirements of individual topics.
Moderate. Requires modification of several content models, and specification of the appropriate constraints to emulate the DITA 1.1 <task> model.
Note: These technical requirements are essentially identical to those first proposed in http://www.oasis-open.org/committees/down.
The feature entails:
Highlights of the proposed DITA 1.2 <task> specialization include:
Support the requirements of the machine industry (and others) for placing admonishments by allowing an optional, repeatable <note> element as a preceding sibling to <cmd>.
Support the use of generic ordered and unordered lists with a new <process> element, child of <taskbody>.
Support of expository text between <step> elements, via a new specialization of <li>, named <stepsection>. This new element provides authors and specializers more flexibility in creating generic ordered and unordered task lists.
Proposed content model for <taskbody>. Note the loosening of the constraints on <prereq> and <context> and the addition of a <section> element before the (steps | steps-unordered) group. <postreq> and <example> are also now optional and repeatable:
(prereq | context | section)*, (steps | steps-unordered | process)?, result?, example*, postreq*)
Proposed content model for <steps> and <steps-unordered>. <stepsection> is a specialization of <li> (sharing the same content model) and supports additional expository text between <step> elements.
Proposed content model for <step>. Note the optional, repeatable <note> element. Note also that <itemgroup> has been added, primarily as a container for specialization.
(note*, cmd, (info | substeps | tutorialinfo | stepxmp | choicetable | choices | itemgroup)*, stepresult?)
Proposed content model for <process>, a specialization of <ol>:
To be supplied.
Risks: Potential mis-use of the less restrictive <task> content model by implementers and authors.
TC Discussion: 1-2 meetings
DTD/Schema modifications: 2 days
Documentation: 2 days
Open Toolkit and Vendor support: Relatively easy, assuming the OT and vendors implement the DITA 1.2 constraints mechanism. No new or special behaviors are being defined.
This proposal will improve the ease of DITA adoption for industries in which the current <step> content model is unacceptably or unnecessarily restrictive.