OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

To date we have avoided interposing new base types into existing type

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.



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> 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]