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

[Kristen James Eberlein <kris@eberleinconsulting.com>]

Sure, but what do we want to have in general task? What do we want to have in the task content model for the troubleshooting topic? How will we handle reuse between task content in a troubleshooting topic and task topics?

Kris

On 5/25/2012 12:13 PM, Eliot Kimber wrote:

Keep in mind that even if we added <tasksection>, the constrained task could
remain unchanged, meaning that it would not allow it.

Cheers,

E.

On 5/25/12 9:19 AM, "Bissantz, Debra" <Debra.Bissantz@lsi.com> wrote:

I agree with Kristen. I haven¹t formed a solid opinion on this topic yet, but
agree that it is a huge change to the standard and requires a lot of thought.
 

- Deb
 

From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf
Of Kristen James Eberlein
Sent: Friday, May 25, 2012 8:01 AM
To: dita@lists.oasis-open.org
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 <http://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