In XML Heresy the Second: Structure Can Take Care of Itself, Larry Kollar discusses structured authoring, and why he thinks “it’s getting far more attention than it needs (or deserves).” The gist of his self-described “heretical view”:  structure is not necessary to enforce “consistency both within a document and across a suite of related documents…a properly-designed style sheet (combined with good old-fashioned peer pressure) is sufficient.”

As you can imagine, Kollar’s views aren’t echoed by consultants who work in the technical communication and structured authoring arena. Sarah O’Keefe, founder and president of Scriptorium Publishing Services, points out several problems with Kollar’s view.

“Structured authoring allows you to define and enforce your required document structure programmatically,” O’Keefe says. “Of course, you can have a (human) editor review your documents to ensure that they conform, but why not let the software validate the documents for you?”

“The ‘peer pressure’ approach does work, especially for small groups where all contributors are in a single location. But as the group gets larger, the value of embedding consistency checking into the software increases,” says O’Keefe.

Steve Manning, senior consultant for The Rockley Group agrees. Manning says Kollar’s article reflects “a very myopic view of technical writing.”

“Sure, a good template and peer pressure might be all the structural control you need,” Manning says. “But only for a smaller department.  This kind of structural control doesn’t scale.  Add writers or add complexity and you have insufficient control over the authoring process.  Then you lose consistency and usability.  And you also miss out on all those other goals (automation, etc.).”

Kollar argues that XML authoring software is often “complex enough to require a support contract (and most large-scale XML authoring systems are), the department is at the mercy of the vendor to make additions or changes — a task that would require a simple style change in an unstructured environment.”

Not so, says O’Keefe.  “A ‘simple style change in an unstructured environment’—there is no such thing. In a group of one or two, it’s relatively easy to make a ‘tweak’ to the styles and distribute it to everyone. But what about when you have a group of 10 or 20 or 50? What if you distribute the new style template and people ‘forget’ to apply it to their documents? How do you deal with updating existing documents? The actual ‘simple style change’ is nothing of the kind—the change management problems are significant whether you are dealing with structured or unstructured documents.”

O’Keefe says Kollar also misses one “major aspect” of structured authoring. “Word processors store documents as a flat sequence of paragraphs (and other document components). Using structured authoring and XML, you can store information about the relationships among the paragraphs (and other components). That is,” O’Keefe says, “you can capture the fact that a title paragraph and the following five body paragraphs make up a section. You can capture the hierarchical relationships between a first-level section and the subordinate sections. You can require that a graphic must be followed by a caption. Storing the document hierarchy like this is a significant step forward, and opens up some very interesting processing possibilities. XML is not appropriate for every publishing workflow. But for some environments, the implementation headaches are far outweighed by the benefits.”

“How much structure you need will always be defined by two things,” says Manning. “How much authoring control you need and how you plan to manipulate the content for output.”

“The first question to ask when you are looking at XML-based authoring,” says O’Keefe, “is, ‘What is the business case?’ In other words, how much will it cost to implement and support XML and what are the benefits? From there, you can have an intelligent discussion about whether XML and structured authoring make sense for that particular organization.”