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" <> 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: <mailto:>
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>
