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.
<-- The "SOAPBOX = ON" reference was meant to be humorous;
Chet--and perhaps others--perceived it otherwise. -->
This is true. I suppose I've been involved in too many discussions where it was
<-- and which Chet didn't request -->
Yes, this is true, too, and I stand chastened.
<-- point out the problems inherent in its 1970s technology which assumes that
documents can be reduced to ASCII text -->
This raises an interesting point. The original design of SGML wasn't based on
notion that all documents could be reduced to text -- ASCII, EBCDIC, etc. It
instead based on a bias to keep SGML documents people, as well as machine,
readable. Now, there has been pressure, movement, arguments, what-have-you
recently that this slant towards people should be jettisoned, and SGML
to be a binary format. I wouldn't want to see it go that way. There is still
value, I believe,
in having an underlying data structure that people can access without some
system or another acting as an intermediary. But gosh, don't I sound old
<-- let's look forward to the day when we can create them without resorting to
primitive technology -->
I think that this points to one of the key issues that has hampered broader
of SGML. The tools that people use to create SGML are still evolving. With a
exceptions, they are still operating on the word processing GUI model. Right
they appear to be little more than word processors with collar tabs in the
they give no hint of the power that the SGML offers. Given that fact, and the
they don't even offer a pretty printout (hence, they actually *rob* the writer
of-use) why should anybody adopt them?
<--and without doing violence to the totality of the document, which includes
physical appearance. -->
Interesting issue. I was thinking about that this morning. Most writers still
their job as producing an output -- paper, hypertext, Web doc, whatever.
This naturally makes the physical appearance of the output a key concern for
I'm interested in a future where we identify our job as producing rich
webs that can be accessed in a variety of ways. The appearance of any one
part of the information will be less of an issue of concern than its usefulness
in a variety of deliverable forms and manifestations. Long way off, perhaps,
but SGML is far more likely to get us there than our current crop of
I guess all-in-all, we are no so very far apart. I apologize to George for
soapbox too literally.