OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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.



Eliot Kimber
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
Book: DITA For Practitioners, from XML Press,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]