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"
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Park Seth-R01164" <seth.park@freescale.com>
- Date: Wed, 21 Oct 2009 11:02:13 -0400
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:
- "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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]