And ditabase is going to need to contain the "strict" task, in order to
maintain backwards compatibility with DITA 1.0 and 1.1.
I find Paul Grosso and Elliot Kimber's reasons as why we should NOT
contemplate shipping two versions of ditabase compelling.
Kris
JoAnn Hackos wrote:
I’m not sure why users
need to convert entire
documents into ditabase when perfectly good conversion tools are
available to
create individual topics. Most tasks seemed to convert to the “strict”
task model reasonably well unless they are really peculiar. In most
cases,
those tasks need to be rewritten, probably before they are converted.
We are seeing very little
positive coming out of wholesale
conversions of books to ditabase when we have surveyed the productivity
issues
around implementing DITA. In fact, the entire idea of “convert first,
think later” seems to have a considerable negative effect on the
ability
of an organization to transition to effective, topic-based authoring.
Therefore,
the argument that ditabase is most appropriate for conversions seems to
me to
foster an undesirable activity and outcome.
However, we find that
many organizations use ditabase not
for conversion but for authoring “collection files” that contain
varied content to be used for conrefs. Usually such collection files
contain
more than one instance of an element, requiring multiple information
types to
be presented correctly. For example, if we want to conref several
pre-requisite
statements (such as equipment lists), we might “collect” them in a
series of tasks in a ditabase file. Putting them into a ditabase
simplifies
content maintenance.
I would prefer that
ditabase contain the “strict”
task topic rather than the “general” task topic to maintain its
appropriate
use for collection files.
JoAnn
PhD
President
Comtech Services, Inc.
Skype joannhackos
