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.
Subject:SGML From:Alexander Von_obert <avobert -at- TWH -dot- MSN -dot- SUB -dot- ORG> Date:Wed, 18 Oct 1995 16:15:03 +0200
* Antwort auf eine Nachricht von Glenda Jeffrey an All am 17.10.95
GJ> From: jeffrey -at- hks -dot- com (Glenda Jeffrey)
GJ> : ** Disadvantages: It takes away your control over how the
GJ> : text looks and how the text fits on the page. It
GJ> : that you consider content without considering form, the
GJ> : message without the medium.
GJ> No. It demands that you consider content _separately_ from
I hardly ever consider form then I write text. You couldn't help but work this
way in the Old Days when I upgraded to Word 4 (from a CPT text system). Output
was through a dasy wheel printer and I could program a break and a beep when I
wanted the wheel changed.
Even today I consider contents and form two widely separate topics. E.g., when
I write for magazines, I do tables something like this:
And if I want a paragraph intended with a caption in front, I do something like
You defenitely have a hard time reading this kind of "formatting", but this
works REALLY great with the DTP people: My files really flow into the layout.
Then they work along the text from top to bottom and primarily add paragraph
GJ> Someone (the document designer) must make decisions up front
GJ> about how the document is to be laid out and presented.
That's about what I do for the DTP operator.
GJ> : It can lead to unrealistic expectations of portability
GJ> : (wow, we can use our brochure as the introduction to
GJ> : our reference manual, our reference manual as our
GJ> : training manual, our training manual as our online
GJ> Maybe. I guess you are saying that people start to expect that
GJ> same information can do triple duty without rewriting. That's
GJ> not SGML's fault -- you can make the same bad assumptions with
GJ> FrameMaker or Word. Remember cut and paste?
As long as you simply use a SGML editor, you hardly get any support for things
like that. If you need it, you need a database publishing system based on
SGML. And exactly here, present SGML technology gets really tough and
GJ> : Advantages: It's sexy.
GJ> Actually, it's really not. SGML as a "language" (many people
GJ> will argue
GJ> that it is not a language, and they have valid points) is
GJ> pretty clunky.
SGML really prevents many "creative" ideas. Your DTD gives you certain
structures, you cannot create others. You have no chance to recycle some
existing gadgets in a creative way, because you have no real control over
formatting. And the technology below the surface is not so polished as you
might be used to.
SGML reduces the freedom of the writer.
Greetings from Germany,
|Fidonet: Alexander Von_obert 2:2490/1719
|Internet: avobert -at- twh -dot- msn -dot- sub -dot- org
| Standard disclaimer: The views of this user are strictly his own.
| From TechWriter's Home, Nuernberg Germany
| phone 49+911+591530, FIDOnet 2:2490/1719