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