With a <tasksection> you'd be able to have something like this:
<taskbody>
<tasksection>
<title>Step Group 1</title>
<fig>...</fig>
<steps>...</steps>
</tasksection>
<tasksection>
<title>Step Group 2</title>
<fig>...</fig>
<steps>...</steps>
</tasksection>
</taskbody>
One design question would be the details of the <tasksection> content
model--should it be open or more constrained. For example, would you want to
require or allow <context> within <tasksection>?
Cheers,
E.
On 5/24/12 4:35 PM, "JoAnn Hackos" <> wrote:
> I agree with Eliot's recommendation. It seems more appropriate to
> specialize the troubleshooting topic from task rather than topic. This
> structural change would allow that to happen. We need to be clear in the
> specification, however, that we do not recommend multiple different sets
> of steps in ordinary task topics.
>
> We have also just encountered an issue with task that suggests a grouping
> of steps. We have a machine industry case in which a group of steps is
> associated with one graphic in a side-by-side configuration on output. We
> would like to have a mechanism that would also us to define a group of
> steps possibly with a title associated with a single graphic. Would
> <tasksection> allow for that?
>
> JoAnn
>
> JoAnn T. Hackos, PhD
> President
> Comtech Services Inc.
> 710 Kipling Street, Suite 400
> Denver, CO 80215
>
> 303-232-7586
>
>
>
>
>
>
>
> On 5/24/12 8: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
>>
>> --
>> Eliot Kimber
>> Senior Solutions Architect, RSI Content Solutions
>> "Bringing Strategy, Content, and Technology Together"
>> Main: 512.554.9368
>> www.rsicms.com
>> www.rsuitecms.com
>> Book: DITA For Practitioners, from XML Press,
>> http://xmlpress.net/publications/dita/practitioners-1/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>>
>
--
Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.rsicms.com
www.rsuitecms.com
Book: DITA For Practitioners, from XML Press,
http://xmlpress.net/publications/dita/practitioners-1/
