Do You Need Structure in Your Life?

By and , Bright Path Solutions, Research Triangle Park, NC, USA.

This is a question that has lingered nearly as long as the history of publishing. And, though publishing has gone on for centuries without structure (structured documentation, that is), its benefits today make the decision about whether to use structure worthy of consideration.
First, let�s address an issue spreading through the technical communication community. Rumor has it that, in a few years time, we�ll all be required to work in structure and use XML. This is untrue.

Structure is not needed in everyone�s life, nor is structured documentation. While working in structure can be beneficial, the benefits are not necessarily realized by all. It is critical to analyze your documentation needs and ensure that your documents will benefit. Otherwise you�and your organization�will expend months of effort implementing a structured document publishing process with dubious results.

In regards to the �few years time� part of the rumor, consider that ten years ago� that would be 1993� few foresaw the sea-change in publishing of providing Web-based information. Against such a backdrop, we suggest that few can predict what publishing trends will occur in the coming decade.

With that said, it needs to also be stated that we are a big advocate of structure. We have seen over the years how SGML and later XML allowed companies to do more with their information than they could without structure. There are great benefits to structure that make the extra investment worthwhile.

Starting Points for Your Consideration

* Description of Structure

The most significant way that structured documents differ from unstructured ones is that structured documents include “rules.” These rules proscribe the order in which text, graphics, and tables may be entered. For example, in an unstructured document, a paragraph has specific formatting� font, size, and spacing. In a structured document, this same paragraph adds to this formatting an exterior �wrapper� or �element� that governs the elements that appear before and after it. The elements’ rules come from a document type definition (DTD).
Basically, you move away from working with formatting and instead work with information rules for how things fit together and when things can occur. In most tools, the formatting is automated so that you can concentrate on your content while authoring rather than on formatting and layout.

* Benefits of Structure

Structure brings to your documents a level of control that formatting alone cannot provide. Using structure has long-term and short-term benefits. These benefits include:

re-use of information

standardization of documents

guided authoring

improved information management

The Horns of the Dilemma

When organizations select a publishing strategy, the question of structured/unstructured documents needs to be answered in terms of both input and output. For authors, structure does mean a �ramp up� during implementation. The return on investment of this up- front time comes in the form of an increased level of standardization and document speed-of-assembly. Documents become quicker to author, quicker to adjust, once the system is in place. Decision makers must weigh the implementation costs carefully against the return�considering the number and type of documents very carefully.

Also to be considered are the publishing outputs and how structure might improve the delivery process. Decision makers must consider, among other things:

How is publishing currently done, and what does the future hold?

If all documents are distributed as hardcopy, then is the structure issue more a matter of style than substance?

What issues are currently being faced? These might include incorrect documents being distributed, long delays for changes, or long authoring cycles due to complex formatting.

For online publishing (XML, HTML, PDF, SGML), the structured/unstructured decision needs to be made in light of the file system. For example, if the output is to be XML, the decision favors structure. Structure provides quality XML element nesting, while unstructured documents (word processed documents, for example) produce flatter XML files. Hierarchy is key in managing XML content in logical chunks, and with logical �wrappers� around the data.

* Information Control

Another consideration is information control. If data retrieval from documents is a goal, then structured documents are the obvious choice. Structured documents can interact with, or in some cases act as a database, with information sorted, extracted, and reused.
For example, a document may be output to XML with a complex hierarchy of data. Using a script or something like an XSLT (transform), certain pieces may be pulled from the XML to produce a new document, Web page, or database entry.

Note: XSLT can do many things and is minimally treated here. An entire article would be needed to explain its potentials.

Another part of information control deserving of its own mention is translation. When sending documents for translation, regular word processing files would be sent for translation in full. With structure, however, additional data (part of a structured document�s metadata) can include information on translation status. This means that each paragraph within a document can be marked as needing translation, translated already, modified since prior translation, and so forth. Companies doing the translation can then selectively translate new and modified content without retranslating content that has already been translated and has not changed. In long documents, significant dollar savings can be realized by translating only information new to this release, rather than translating the entire document �from scratch.�

* Consistency

Documentation consistency issues also figure into the structured/unstructured debate. Since the days of SGML, many companies have selected structure as a means of enforcing document consistency. Structured document publishing guides authors as to what pieces of a document are required, and how they should be pieced together. This allows some standardization and avoids author-biased decisions about content.

Within workgroups, each author holds biases and preferences, any of which can be good or bad. Multiple authors working the same document may each organize their chapter in a different way. Structure adds rules to prompt authors, providing extra control. So, structure is a very good direction for organizations that need to enforce consistency.

* Publishing Plans

When implementing documentation tools and processes, there is a period of time within which more effort is expended organizing processes and coming up-to-speed with tools than producing documents. Efforts to have the authoring and publishing automation tools up-to-speed need to be considered. Familiarity with structured documentation tools will add time to this phase of the publication of a document.

If structure is selected, then a DTD must be developed. Development and testing of a DTD may take from several weeks to many months. The additional ramp-up time for structured documents is significant; however, some industry standard DTDs are available to shorten this time. (Editor�s Note: Check out the DocBook DTD).

Beyond implementation, an additional consideration is troubleshooting time. All this time must be accounted for in the publishing plan.

* Industry Requirements

Another part of the structure decision has to do with what industry your company is in. Many industries were early adopters of structure and have been reaping benefits for years. Because of their involvement in structure, some companies will insist upon working in structure to be able to interact appropriately with others in their industry.

One example of this is the airline industry. Many airplane equipment manufacturers use SGML for their documentation. Airlines that purchase the equipment are provided with SGML so that they may integrate the manufacturer�s content with their own end-user (pilot, for example) documentation. While not all airline documentation is structured, a great number of airlines have jumped in with the manufacturers and use the SGML or even XML to produce structured documents. This allow them to share content more easily, and to push their content out to �tagged� PDFs and other formats for handheld devices. Worthy of note is the fact that they have lost no capabilities on the paper publishing side, and are able to continue producing printed manuals when desired.

* Return on Investment

There is not a specific kind of documentation that needs structure or guarantees a return on investment in structure. However, most documents can benefit from structure. The return on investment may be difficult difficult to calculate or foresee.

Many organizations manage just fine without structure: they publish a variety of documents and all goes well. The need for structure is based less on the kind of document and more on the publishing scenario within your organization. Reviewing the above mentioned benefits, you will need to determine if you face any issues or are working harder than is necessary for your publishing goals.

Knowing the types of scenarios that can be improved by structure, you need to determine what costs will be involved, and if your volume, needs, outputs, and so forth will benefit sufficiently from structure.

* Out-of-Pocket and Other Costs

Tools for working with structure (or directly in XML) vary in cost from under $100 to several thousand dollars per seat. The costs for personnel and overhead are significantly higher than the cost of acquisition for such tools.

The extra level of difficulty and discipline in structured documentation means increased personnel costs. With structure, you find that at least two types of personnel are needed: document designers (DTD authors) and subject matter authors. (Others such as Webmasters, database managers, etc. are not dealt with herein but may be needed.)

Technical personnel that design and manage DTDs and produce templates require a more technical knowledge than the subject matter authors. The most technical team members command a higher salary. Salaries for XML-savvy and structure-savvy personnel are much higher than without. XML is a hot technology, with few experts in the field. (In fact, just this year we have officially reached the point where someone might have 5 years of XML experience.) It can be personally, economically rewarding to learn structure. It may make you more marketable. That is a nice side effect of your moving your current company to the next level of publishing.

The other cost consideration is the training cost. Ramp-up time for structure and XML lengthens without training: some software organizations estimate 3-6 months just to get up-to-speed on authoring and publishing tools and to get basic documents started. With training, personnel begin using the software effectively right away. Technical training costs can vary, depending on the tools and technologies, but usually cost hundreds of dollars per day/per student. This training increases up-front costs, but also significantly increases the return on investment in structure by accelerating document delivery.

Summary

Unstructured documents usually let you perform all the paper and electronic publishing you need, but structure has significant benefits and in many cases represents the best path. Not all organizations will need structured documents. Structured document publishing requires higher initial investments of both time and money. Depending on the publishing strategy, however, this can be recouped on the back-end and represent significant savings into the future.