Re: [dita] strict task vs. general task vs. the file naming andmodule rules

[Eliot Kimber <ekimber@reallysi.com>]

On 11/13/09 2:20 PM, "Joann Hackos" <joann.hackos@comtech-serv.com> wrote:

> HI--
> 
> Iım really opposed to this option (1). There is absolutely no way we can
> possibly inform everyone using DITA today that theyıre in for big problems.
> Are all of the vendors of all the editors willing to place warnings on their
> releases, which should have happened with Arbortext 5.4? How will we
> communicate the problem? Most users donıt even know of the existence of
> dita.xml.org or any of the documentation from either TCs.

To recap, this change affects the following users:

- Users using topics that are specialized from task and that *did not*
define new content models for taskbody. That seems like a very small
potential set, since most reasons to specialize from task would be to
further refine the details of the task body (e.g., specialized prerequisite
markup, etc.), which means your specialization already reflects the 1.1
strict model and that won't change with a move to 1.2. Any group this
sophisticated can probably handle the migration without difficulty and has,
in fact, probably been waiting eagerly to be able to have a more flexible
topic model to specialize from.

- Users using local shells for the base task topic type. These users will
see unconstrained content for topicbody until their shells are updated to
integrate the TC-provided constraint module. The update task is easy to
do--just copy the relevant lines from TC-provided task.dtd into your
task.dtd. 

This group is probably a *bit* larger, but if my so-far-quixotic attempts to
get the community at large to understand the need for local shells is any
indication, there aren't too many groups using local shells. Certainly very
few users of Arbortext, XMetal, or FrameMaker are.

Note that the issue with the current release of Arbortext Editor 5.4 is
*not* the result of this design change, it is the result of a mistake made
by the Arbortext Editor development team. That mistake can easily be fixed
by using a fix to 5.4, something PTC will have to do when 1.2 is
sufficiently stable in any case, in order to reflect other late changes
we've made to the markup design. So I think we can assume that the current
Arbortext Issue will be resolved before or very soon after DITA 1.2 reaches
the final stages of approval.

Oxygen points to strict task because it uses the TC-provided shells and
modules without modification.

As far as publicizing the need for migration, I think we can easily include
an appendix to the 1.2 spec that lists migration items and how to address
them in moving from 1.1 to 1.2.

I don't think it's going to come as a surprise to any 1.1 user that 1.2 is a
significant change to DITA.

We also have the DITA Users news group as well as the other channels used by
the DITA Adoption TC.

Cheers,

E.

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 610.631.6770
www.reallysi.com
www.rsuitecms.com