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

[Eliot Kimber <ekimber@rsicms.com>]

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

-- 
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/