SGML & The Technical Writer

Subject: SGML & The Technical Writer
From: Steve Owens <uso01 -at- EAGLE -dot- UNIDATA -dot- COM>
Date: Tue, 12 Apr 1994 13:41:52 +0700

> Gerry's quote is not out of context--that's the problem. I've heard an
> expert say it in an SGML meeting here in New York and one of the Tech
> Comm writers (in the first set of papers Liora Alschuler edited)
> repeated it in her paper.

The quote MAY be out of context - we certainly haven't seen it
in its original context, and the context created by the poster may not
be faithful to that original context.

> Also, I'm not saying Postscript is the ultimate solution. However, it
> works, and getting it accepted in the market didn't seem to require a
> lot of beating around the head and shoulders.

Do a little research on it sometime, I think you'll find it
took a lot more work to get it accepted than you may think. Oh, and
postscript still isn't a universal standard. I think one of the major
reasons postscript was accepted was the preponderance of hardware
devices (mostly printers, but some operating systems and such) that
take advantage of it.

> Interleaf and Framemaker RIGHT NOW solve the problems of
> cross-platform display and file manipulation. Plus they both have SGML
> filters for those of us who are forced to use SGML. Why struggle, for
> heaven's sake?

Mm... again, I think you have a little too much faith in the
availability of those products on all platforms (my company's product
goes out on 20 different flavors of UNIX, for example), and a little
too much faith in their effectiveness (more than once I've seen filters
that only did half the job - I haven't seen Interleaf or Frame4 filters
yet, so I can't speak to those, but I'm not about to blithely accept
a marketing department's promise about their product).

> I, too, look forward to the day when SGML is the native format for all
> word processors--there's no good reason that w-p's should
> differentiate themselves in the marketplace by proprietary formats. I
> have one caveat, however: SGML forces a particular structure on a
> document (head1>head2>head3>etc.), which is what leads to all these
> error-message interruptions. (The ideal SGML system would be one in
> which you turn off the structure checking while you write, then turn
> it on when you're ready to do a final version--like a spell-checker or
> grammar-checker, but in this case a structure-checker.)

Hm... again I run into the limitations of my knowledge (of
SGML). I'd bet money, though, that the problem is in that particular
implementation of SGML. Framemaker, for example, with its paragraph
formats (if you use them properly), is not too different from SGML.

> As for jumping through hoops: why don't we ask TECHWR-LIST for some
> real data? Estimated time before SGML project started, actual time
> required, and are you satisfied with the results?

This would only produce valid data if you accurately surveyed
the hidden costs and improvements, which span multiple projects,
particularly when one project involves importing information from an
earlier project, or updating it. SGML forces you, as one poster said,
to think through the structure questions explicitly, and up front, in
doing the DTD. It also saves time in the long run as it makes moving
information between documents easier, as it makes formatting a document
easier because you already have a developed "look", and so forth.

There are time costs involved with thinking through a process
when it hasn't been taken care of by using SGML. There are increased
time costs from not single-sourcing, which isn't practical when you're
not using an SGML-style system. There are increased maintenance costs
when some of the formats may have minor variations that you have to
account for. The list goes on and on...

The trick, with SGML applications, will be developing products
that address these issues without making the writer feel constrained -
for example, if I were using an editor that *forced* me to address a
header incongruency RIGHT NOW, instead of letting me finish doing a
braindump and return to massage it and reformat it, I'd be exceedingly

Steven J. Owens
uso01 -at- unidata -dot- com

Previous by Author: SGML & The Technical Writer
Next by Author: gender, sex & biology
Previous by Thread: SGML & The Technical Writer
Next by Thread: Re: SGML & The Technical Writer

What this post helpful? Share it with friends and colleagues:

Sponsored Ads