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

[JoAnn Hackos <joann.hackos@comtech-serv.com>]

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
>