I support the idea, as it would simplify many things. There is no good reason to treat step and substep differently, except avoiding unlimited levels of nesting. That is not something to handle in a standard like DITA - it should be part of content strategy training and it could be handed to authors as guidelines.
Having just sent in regrets for next week, I'm going to stir the pot with a controversial idea.
I've been asking IBM authors what they want from DITA 2.0. One of the more common responses so far is "get rid of substeps" -- meaning, just let <steps> nest.
The reason we have <substeps> is so that task can enforce (what DITA 1.0 designers considered) good information design. That is: if you've got three levels of nesting, that's too much for a single task, and you should break the task apart. If <steps> nests, that allows task to have 3 or 5 or 20 levels of nesting, just as with <ol>.
I've heard several counter-arguments in the last few days:
- There is no semantic difference between step and substep, so it's frustrating to have two sets of elements
- It prevents copy/paste or drag/drop if you try to turn one into the other
- If a step in one task is reused as a substep in another, you cannot conref the whole step - instead you have to conref every child of the step
- The limitation isn't even effective, because people just put <ol> inside the substep's <info> element
- If an author / a team / a company want to limit nesting, there are other ways to do that, such as Schematron rules or build / formatting rules
Given the design history and potential migration cost, I didn't think the TC would look kindly upon this idea, but then the arguments started to pile up, and I wondered if the rest of you were hearing the same thing.
Curious as to your thoughts...
|