Re: [dita] 1.2 Proposal: Re-create "general task" from "topic"

[ekimber <ekimber@reallysi.com>]

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" <seth.park@freescale.com> 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:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
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>