Roles and responsibilities in XML publishing
The roles and responsibilities in an XML (and/or DITA) environment are a little different than in a traditional page layout environment. Figuring out where to move people is a key part of your implementation strategy.
- Domain knowledge (expertise about the product being documented)
- Writing ability (duh)
- Knowledge of the template and formatting expertise in the tool being used
For a structured workflow, the first two stay the same, but paragraph and character styles are replaced by elements. Formatting expertise is less critical—the formatting is embedded in a stylesheet, which is applied to content when it is time to create output. Knowledge of copyfitting and production tricks is no longer relevant and can even be detrimental if the content creator insists on trying to control the output by overriding default settings.
The content creator needs less template and formatting expertise, especially if the content is highly structured and provides guidance on what goes where. Generally, content creators need to focus more on how to organize their information and less on how to format it.
The role of the technical editor (assuming you are lucky enough to have one) also changes. Document structure is enforced by the software, so technical editors can focus on overall organization, word choice, and grammar. Technical editors are often responsible for reviewing large amounts of content. This perspective can be helpful in establishing an information architecture.
Speaking of information, we have the information architect, who is responsible for determining how information should be organized and tagged. Typical tasks for the information architect are:
- Developing guidelines for topic-based authoring (for example, how big should a topic be?).
- Establishing rules for tagging. For example, when should an author use the <cite> tag and when the <i> tag?
- Organizing shared content and establishing guidelines for reuse.
The equivalent responsibilities were typically handled by the technical editor and the production editor in an unstructured workflow.
In an unstructured workflow, production editors are responsible for finalizing the layout/composition of unstructured content. They typically have deep expertise in the publishing tool and know all of the tricks to make output look good. Very often, production editors are permitted to override templates to copyfit pages and make the final result look better.
The role of the stylesheet programmer is new in an XML workflow and replaces the production editor. The stylesheet programmer creates a script that transforms XML directly into output (such as PDF or HTML). In effect, the handiwork of the production editor is replaced by a script. Stylesheet programmers need a thorough understanding of XML and especially of publishing scripts, such as XSLT, but they need almost no domain knowledge.
Here are the typical roles in a structured workflow:
Did we miss any? What do you think?
Portions excerpted from our Structured authoring and XML white paper.