TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
<snip>
From: Tim Altom
I'm sorry, Connie, but I must disagree. Structure can exist quite
independently of content, and often does. This is the basis for all of SGML,
in fact. Databases aren't developed with content, but with structure...the
content comes later. If you can work with DocBook, the mammoth DTD developed
for SGML documentation, you'll find that it works for just about every
possible situation...all with no content being added yet. Haven't you ever
written an outline for an English class before you started writing? That's
structure predating content.
</snip>
Structure may precede content being entered into the structure, but any good database or English Comp. paper requires that the authors know what kind of information goes into the structure, before they begin. It is impossible to write a good outline without researching the topic beforehand and knowing what you are going to say. A good database should suit the data, not just act as a repository. The idea that databases are meant to store data is missing the point. Databases are meant to store information, which means presenting the data in a useful way, which means taking the nature of the information into consideration before you begin.
Data warehousing only works if you know how the system will be used (i.e. what data it will contain) before you set up your tables or your star schema. A bad outline cannot save a horrible paper, and many papers require at least minor reorganization midway through the editing process (if there's time, two. ;).
As others have stated, the chicken and egg syndrome applies here. You can't set up a useful database with a generic view of the data, you can't use a database that doesn't have a suitable structure.
<snip> Structure can and should come before content, because the entire documentation cycle can be defined and tested before you write word one. Structure definitions also make it possible for various writers to work together without bumping too badly into one another. It permits single source technology to be deployed without having to wait for content to be written. I've done several projects in which I knew IN ADVANCE how my links were going to be distributed in a help file, despite having not written a single topic. That permitted me to create a shell file, which in turn permitted developers to work on both linkage and output issues, and let me design and test templates, styles, mappings, and other hooks. </snip>
Again, mileage may vary. Your documentation process *should* vary depending on what you are documenting, the needs of your users, etc. I think that declaring that you will apply single source technology, or <insert neato-keen tool/e-business strategy here> to the information before you even look at it is using tools for the sake of using tools. I think that considering structure at an early stage in the documentation process can be helpful, but I also think that focusing just on that can close off avenues and opportunities to do the job in the best way possible for the content at hand.
