Re: ANNOUNCEMENT: My book on SGML has been published

[John Gough <gough -at- AUSTIN -dot- ASC -dot- SLB -dot- COM>]

> The title is "$GML: The Billion Dollar Secret," and it is the third volume
in
> the "Charles F.Goldfarb Series on Open Information Management" published by
> Prentice-Hall. The target audience is managers who have to understand the
> problems with publishing technical information and sign off on what
systems and
> standards their organizations should adopt.

Congratulations, Chet!

I do have a question: does the book examine the cost side of implementing
SGML in a large organization? Does it examine the issues of user interface
for authors and readers? Does it cite resources and time required to develop
it?

There were two excellent papers at SIGDOC 96 in RTP, NC this year.
IBM RTP and SAS Institute gave details of (a) how they developed their
systems,
and (b) how typical document production worked, from authoring through
production.  In both situations implementation called for significant
(massive is probably a better word) resources committed over a long time to
develop all of the tools necessary to support authors, data storage,
conversion, and production.
The estimate I got from one of the SAS people was that it took 30 people
two years to work out all of the kinks--and that got them to the prototype
stage.

Too many books blithely hype SGML as a cure-all .
Too few address in detail the substantial issues
surrounding design and implementation, or the dependencies a successful
implementation has on organizational structure and cooperation.
I am currently working with some managers who are being pushed
to accept SGML (including responsibility for maintenance!), but do
not have resources to support it (2 tech writers, no support programmers) nor
an adequate understanding of it (by their own description, not my
criticism!).

Off the top of my head, here are some of the big issues that
often get ignored:

1. Authoring interface. Productivity is a big issue here, because
companies usually scrimp on hiring authors. Frame or Interleaf
are examples of high-productivity interfaces. I haven't seen Abortext's
most recent offering, but most of what I've seen has authors working in
ASCII or with a WYSIWIG interface with severely truncated features.
IBM addressed this issue with front-end filters. SAS is going to
use Arbortext's new product. Interleaf and Frame
have offerings that allow you to produce SGML. From what I have heard
you usually have to do some hand-tweaking as well.

2. DTDs. There are a lot of forms of communication out there, each
with its own visual style:  training, documentation, marketing, business
communications, reports, etc.  It is a challenge to come up with a set
of tags that allow information elements to travel well between contexts.
SAS spent time with this issue.

3. Production filters. SGML browsers represent a "special case" way
of thinking. Both IBM and SAS planned to use filters to convert SGML to
Windows Help, HTML, or other more univerally accepted forms of output.

4. Training and documentation. You have to invest in these both to
create acceptance and to create the level of competence in use that
overall productivity depends on. SAS had built this into their plan.

See http://web.mit.edu/org/t/tps/www/NL/SIGDOC_WWW/sig96/
for SIGDOC 96 information. The papers by IBM and SAS are published
in the proceedings.

Sorry for the long post, but reading the book hype on the publisher's web
page pushed my "magic bullet" buttons. This post is *not* a criticism of
Chet's book, which I have not read (but hope to). It's more a response
to a certain quality of zealotry that I have encountered in some proponents
of SGML. I like SGML as a technology, and respect the value that
it represents, but I think its use should be approached critically and
carefully.  It's a big investment.

Is anyone else working on SGML process implementation
or technology evaluation, especially for technical
documentation and training materials? I'd be interested
in swapping stories. I'm especially interested in how smaller-scale
operations manage to get started. The price of entry seems
to be quite high.

Speaking strictly for myself,
John

"The least examined assumptions are often the most questionable."
--
John Gough                                gough -at- austin -dot- asc -dot- slb -dot- com
Technical Consultant                             johngough -at- aol -dot- com
Schlumberger  --  Austin Product Center C1.147  --  (512) 331-3656

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html