1.2 Proposal: Re-create "general task" from "topic"

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