One of our customers, a big software development company, used XML to describe configuration parameters of their software. The software read the configuration XML file and behaved accordingly. The amount of the configuration parameters was enormous: the XML file included 6,000 parameters, and each new release only increased this number.
The problem was that all these parameters had to be documented. Can you imagine a technical writer copying-and-pasting these parameters from the configuration file to the authoring tool? To make things even worse, engineers updated the configuration file quite regularly so copying-and-pasting was part of the writer’s daily routine.
But to let you feel a real scale of the challenge, think about this: the configuration parameters were also part of the internal requirements and design documentation. This documentation was created mainly by system architects for internal use by other architects, product managers, engineers, and support team. The system architects were not particularly happy wasting time on the copy-and-paste work either, leave alone a bunch of inconsistent and outdated information in the documentation.
We moved their documentation to XML and built a mechanism that parsed the XML configuration file and automatically integrated the configuration parameters into the product and requirements documentation. The data about parameters was rendered into nice looking tables that were easy-to-read and understand.
From now on, every time the configuration file was updated, the relevant documents were automatically updated too. Yet, the authors would have to add some narrative (like descriptions for human readers, for example), but at least they could be sure that the documentation now included up-to-date information and it’s synchronized with the XML configuration file.
In another project, the customer (a semiconductors company) had data about registers and boards stored in a database. This information was part of both user manuals and internal requirements documentation. Just imagine the amount of copy-and-paste work as well as the scale of unsynchronization between the documentation and the information stored in the database.
After the documentation was moved to DITA, we’ve built a solution that retrieved the data from the database, converted it to DITA tables, and integrated them into the documentation. Every time the database was updated, the documentation was automatically updated too.
This is what is so great about DITA. Once you have content in a structured format, you can integrate it with other data whether it’s stored in a database or another XML format. The benefits are obvious: