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