[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Is a <tasksection> Element Appropriate?
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]