Re: [dita] Is a <tasksection> Element Appropriate?

[Kristen James Eberlein <kris@eberleinconsulting.com>]

I want to be cautious about making changes to <task>; I think what you are suggesting would loosen WAY too many things in the task content model.

Strictly from the perspective of the proposed troubleshooting topic:

If the reason to add a <tasksection> is solely to accommodate including <steps> in a troubleshooting topic, then I think the price might be high, especially as the tactic of embedding <task> in the a troubleshooting topic type (as the IBM troubleshooting specialization does) works reasonably well.

I think that we'd need to do a careful cost and benefit analysis ...

Best,
 
Kris
 
Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 5/24/2012 10:56 AM, Eliot Kimber wrote:

Based on Tuesday's discussion of the troubleshooting topic strawman
proposal, we observed that the design used <steps> within <section>. This is
not allowed by the current model for <taskbody>, which only allows <steps>
within <taskbody>.

This made me think that perhaps we need a <tasksection> element that would
then allow <steps>. This would both allow organization of tasks into titled
groups of steps, which I know people have asked for, but would also then
allow Bob's troubleshooting topic to be a proper specialization of <task>.
As troubleshooting is fundamentally procedural in nature, it makes sense to
me for it to specialize <task>.

I think it would be as simple as defining <tasksection> to have a content
model of %section.content; + <steps> and allow it to occur as a repeating
alternative to <steps>.

It would have to be repeating to accommodate the troubleshooting model but I
think repeating is appropriate since it allows for distinguishing titles,
which <steps> by itself does not (and therefore multiple <steps> would tend
to be odd or ambiguous).

This issue also points up the historical problem we have in that things
that, in hindsight, should have been defined as domains were not, <steps> in
this case. But there's no way to correct that now without making
backward-incompatible changes to specialization ancestry.

Cheers,

Eliot