[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Is a <tasksection> Element Appropriate?
I want to be cautious about making changes to
<task>; I think what you are suggesting would loosen WAY too
many things in the task content model. Strictly from the perspective of the proposed troubleshooting topic: If the reason to add a <tasksection> is solely to accommodate including <steps> in a troubleshooting topic, then I think the price might be high, especially as the tactic of embedding <task> in the a troubleshooting topic type (as the IBM troubleshooting specialization does) works reasonably well. I think that we'd need to do a careful cost and benefit analysis ... Best, Kris Kristen James Eberlein Principal consultant, Eberlein Consulting Co-chair, OASIS DITA Technical Committee Charter member, OASIS DITA Adoption Committee www.eberleinconsulting.com +1 919 682-2290; kriseberlein (skype) On 5/24/2012 10: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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]