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