[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] 1.2 Proposal: Re-create "general task" from "topic"
If we had a general-task topic type then constrained task would need to be a specialization of it in order to have a single type hierarchy of task-nature things. To date we have avoided interposing new base types into existing type hierarchies. Certainly this approach was considered during the initial discussion around the need for a more general task model--would have to review the archives to see why it was rejected, but I think it was generally on the "we can't add a new base type" argument basis. Cheers, Eliot On 10/21/09 9:49 AM, "Park Seth-R01164" <firstname.lastname@example.org> wrote: > The need for specialized expertise to sort out local shell conflicts > created from different domain (constraint or otherwise) usage is > unavoidable. However, the advent of general task is pushing this > conflict into the hands of the most basic users who expect--rightly or > not--that DITA can be used as an out-of-the box solution without shell > configuration expertise. > > So, I propose we walk away from the current implementation of general > task as a constraint of task. Instead, create a new general task > specialization from base topic? > > This would mean a new top-level element name (<general-task>), a new > body name (<general-taskbody>), a new MOD file (general-task.mod), a new > DTD shell (general-task.dtd), etc. > > This would resolve: > > * "Which task model to include in dita base" -- Include *both* of > them. > * "Can we conref" -- Because they are clearly different DTDs, the > assumption will not be "yes, of course... they're the same thing." > * "Should we rename task.mod" -- Clearly no. > > I think it's philosophically a great idea to create task as a constraint > of general task, but it's simply causing more trouble for our basic > users than it might be worth. > > I know it's late in the game, but the creation of this structural > specialization would be simple to do; it would affect only the > terminology in a few papers by the Adoption TC and the few articles that > describe the "making of" general task. Ultimately, I think it would > require less effort for us, tool vendors, and the general user > population. > > > > -seth park ---- Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc. email: email@example.com <mailto:firstname.lastname@example.org> office: 610.631.6770 | cell: 512.554.9368 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403 www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>