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.
Come now, Andrew...structure can exist quite nicely without content, thank
you very much. SGML and XML aren't theories, but actualities, and they both
operate on the principle of structure being utterly independent of content.
For that matter, HTML is also (weakly) a structuring system that does not
depend on content for its existence. Content holds up nothing. It is the
filling, not the shell. If you've ever designed a DTD, you'll know the
Actually, almost any designed system can have structure without content. A
database can exist as a schema, without data point one. A network node can
exist without data, but with hardware, software, and protocols that permit
it to act as a node. To use your own example, a building can stand very well
on its own with no inhabitants at all. Look at the pyramids of Egypt as an
instance. Structure and form, no contents.
OOP programmers often design software with storyboards, complete to the
level of methods and attributes, without a single electron changing state or
line of code springing into existence. Again, structure exists without
This is not a mere quibble, but a serious design issue. I personally believe
that our profession has been enormously disserved by the "ready, fire, aim"
attitude that many of my colleagues espouse. Engineers, doctors, lawyers, et
al don't learn their crafts in school, despite your misunderstanding of that
fact. Rather, they're taught the rudiments, enough to learn well later on,
and they're taught *how to think*. Ask any lawyer and he'll confirm this. I
spent some time there; I know. And I'm on the industrial advisory board of
the local engineering school here. I'm well aware of how their education
takes place. Lawyers learn the law after they're at work, not in law school.
And the bar exam doesn't test a "right-wrong" grasp of the law, but a way of
thinking about applying laws to situations.
All professions do this, because the hallmark of a professional is the
ability to apply the thinking processes he's learned to new situations. By
contrast, many of us in tech doc come off as hunched-over scribblers,
muttering to ourselves, constantly reinventing the wheel to make ourselves
feel important and unable to point to a single truly professional thought
pattern that all of us can share. We don't engineer documents; we let them
grow, like meadow flowers. Or we apply our own singular personalities to
them and crow like roosters about it.
If we do not produce documentation methodically, we can't fix problems with
it. We can't identify what works and what doesn't. We can't justify
expenditures. We merely defend our work with analogies and vituperation.
Many other, related, fields are moving strongly to correct similar problems
in their ranks. If we don't, we'll continue to be seen as fallen angels,
people who couldn't make it as real creators of goods, but only as twisted
poets and typists. In my mind, the lack of ability to see beyond "content
good...other people stupid" is symptomatic of the entire problem. The
temptation to leap into a project and start churning out pages is, indeed, a
strong one. And the tendency to equate activity with progress is perhaps
even stronger. But experienced professionals know that a painstaking design
up-front saves enormously later in the project. Mistakes caught on the
drawing board are cheap to fix; mistakes caught at printing are horribly
expensive. The whole point of professionalism, design, planning, structure,
and process is to catch those mistakes before they grow into monstrous size.
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
> Structure cannot exist without content. Because structure needs content to
> it up.