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