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

[Eliot Kimber <ekimber@rsicms.com>]

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" <joann.hackos@comtech-serv.com> 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
> Joann.hackos@comtech-serv.com
> 303-232-7586
> 
> 
> 
> 
> 
> 
> 
> On 5/24/12 8:56 AM, "Eliot Kimber" <ekimber@rsicms.com> 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: dita-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: dita-help@lists.oasis-open.org
>> 
> 

-- 
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/