Why Create Content as Data Modules

As you can imagine, working with data modules rather than documents is a significant paradigm shift for authors, editors, reviewers, and anyone working within a technical publications organization. So what is the benefit of working with data modules and adjusting to a completely different way of creating documentation?

Automation and Reuse
Because data modules are identified and written according to component and information type, it is very easy to reuse data modules across multiple publications and publishing outputs. When a data module is updated, that change impacts every publication in which that data module occurs.

Because data modules contain identical metadata across all data module types and have data module codes that identify the component and type of information, it becomes easy to pre-populate much of the metadata and even some of the content in a data module simply by interpreting the information in the data module code. This is accomplished by means of a Data Module Requirements List (DMRL)—an S1000D concept used for document planning—which identifies the systems associated with each component of the Data Module Code. The DMRL can be loaded into a Common Source Data Base to establish the information requirements for the entire project; and based on the DMRL, all of the needed data module objects can be pre-created in the appropriate hierarchy in the CSDB.

What this means is that by the time an author is prepared to write about a component, there is already a data module object in the CSDB with all or most of the needed metadata (revision information, inwork status, security classification, etc.) and some of the content pre-populated. The data module object in the CSDB can also be pre-populated with the appropriate XML tagging structure, so the author simply needs to apply the content for the module (e.g., the installation procedure for a brake rotor) into the correct XML elements and check it back into the CSDB.