dita — archive
DITAbase for conversion
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:[email protected]" type="cite">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