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"



I did think about this, but there are some real problems.

It will mean either new element names for every existing task element (eg <step>, <cmd>, etc.) in the ancestor, or a change to the class attributes for those elements moved to the ancestor to reflect their new home (eg <step class="+ topic/li generaltask/step ").

If we change the element names, none of the existing stylesheet overrides for task will work for general task.

If we change the class names, none of the existing stylesheet overrides will at all.

Also, specializers would need to include the ancestor generaltask.mod in their specialization shells to create a valid doctype. If they just included task.mod, it would create an error. So it's the same problem as with constrained task (specialization shells are affected), except that the result for unaware migrators would be a broken DTD rather than a looser task model.

Michael Priestley, Senior Technical Staff Member (STSM)
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25


From: "Park Seth-R01164" <seth.park@freescale.com>
To: "DITA TC" <dita@lists.oasis-open.org>
Date: 10/21/2009 10:50 AM
Subject: [dita] 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: 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



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