Re: Real value (was implementing single-source) - demonstrated!

["Tim Altom" <taltom -at- simplywritten -dot- com>]

I'm sorry, but my reply is, bluntly, "balderdash". The system you possess
and despise is a poor example of state of the art, I'm afraid.

First, I have extensive experience working with my colleagues converting to
single source, and I can confidently say that not one out of ten can seize
the concept of truly structured writing within the first week. Even those
who do often resist working with it. The idea is too foreign. By
"structured", most of them are thinking in HTML terms, which mimics
structure but does not define it. They think that using "heading one" at the
top of the first page in a chapter is structure. It is, the same way that a
kite is a flying machine. In single source, however, if a structure cannot
be rendered as a DTD, it isn't structured at all.

Now, it's also the case that some of those who grasp the idea of structured
documentation take to it like a hound after a soup bone. The benefits of
single source and structure are plentiful and obvious once the environment
is built appropriately.

Second, it's possible to embed movies in PDF, in HTML, in XML, in SGML, in
WinHelp, and in other file formats. Movies aren't needed in print, but print
is rapidly becoming a fallback format, not a primary one. By keeping
information in SGML/XML, it's entirely feasible to have much more
information than you momentarily need stored in documents or a database,
then extract only what you need at the moment. Write a DSSSL or XSL
transformation for each purpose, and you can produce whatever you want on
the fly, in real time.

Properly designed, the document structure does NOT change from product to
product. It has no need to. A correctly designed DTD abstracts whatever you
will need to do, with minimal tweaking over time. An incorrectly designed
DTD is a nightmare. Unfortunately, many companies bleed their single source
projects, then moan about the rickety structure not living up to its
specifications. A good DTD essentially defines a documentation warehouse,
which can be searched for anything you want: marketing descriptions,
stepwise instructions, reference tables, graphics, movies. A
transformational document or script does all the assembly work. To the end
user, there is now a truly new document; the back-end work is totally
invisible. To all appearances, the entire document has morphed.


Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info
http://www.simplywritten.com

----- Original Message -----
From: Glenn Emerson <gemerso1 -at- rochester -dot- rr -dot- com>
To: Tim Altom <taltom -at- simplywritten -dot- com>; TechDoc List
<techwr-l -at- lists -dot- raycomm -dot- com>
Sent: Wednesday, November 22, 2000 1:59 PM
Subject: RE: Real value (was implementing single-source) - demonstrated!


> Tim Altom wrote:
> >>Now, single-source does impose something most writers and managers find
> hard to accept: discipline. To produce reliable output, you must have
> reliable
> input, and that means defined and predictable structure.<<
>
> Your obvious contempt for technical writers and their professional ability
> aside, you have just proved my point. The leviathan system is inflexible.
>
> By "reliable input" read: well-structured text & static images only. (Show
> me how you can SINGLE SOURCE a motion picture to print and I'll give you a
> cigar.)
>
> Predictable structure is a hallmark of good technical writing, and has
> nothing to do with a gargantuan single source monolith. That predictable
> structure can change, from product to product, based on changes in the
> educational needs of the target population, etc. However, the leviathan
> single source system cannot change so easily. One size must fit all,
because
> it's too costly and time consuming to adjust the DTDs and conversion
> routines when a new training or documentation design is prescribed by
> funding constraints or market requirements.
>
> Of course, none of that matters to the IT/IM types. That's just
> "undisciplined technical writers trying to stick things in somewhere." The
> motto of IT: "Machine uber menschen."
>
> Regards,
> Glenn Emerson
>


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by SOLUTIONS, Conferences and Seminars for Communicators 
Publications Management Clinic, TECH*COMM 2001 Conference, and more 
http://www.SolutionsEvents.com or 800-448-4230

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.