Re: [dita] Content model options for #12011 - Generic Task Type

Michael Priestley <> wrote
on 28/11/2007 02:34:27 PM:

> I'm inclined to think that if a task has more than one set of steps,

> it's not a task. 

It's these kinds of absolutes that should be enshrined
somewhere in doctrine.  No, seriously.  By having rigid boundaries
like this, specializers who want something outside of them know to not
pursue one course (subverting <task>'s content model) and to pursue
others (specializing straight from <topic>).

> Rather than create alternates at the <steps>
level, could we 

> preserve the requirement for a single set of <steps> but allow
more 

> freedom within it? In other words, instead of adding <ol> and
<ul> 

> as peers of <steps> and <steps-unordered>, just allow
<li> as a peer

> of <step>. And add a new specialization of <li> - <discussion>
- 

> that has override behavior to appear without numbering or indenting

> (ie it interrupts the flow of the task but not the numbering of the
steps). 

I could certainly live with that.  On the other
hand, implementations will have fun numbering steps now that some children
of <steps> don't increment the numbering.  On the gripping hand,
specializers desperate for <simple-step> would have a place to hang
their element.  I wish I knew if that was a good thing.

> That leaves the question of what kinds of generic containers to 

> allow before and after <steps>.

If I had to choose between the current proposed content
models for <taskbody>, I'd probably choose Eliot's (with a <process-description>
element) because of its symmetry.

-- 

Deborah Pickett

Information Architect, Moldflow Pty Ltd, Melbourne