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:RE: Giving up on XML From:"Lauren" <lt34 -at- csus -dot- edu> To:"'David Neeley'" <dbneeley -at- gmail -dot- com>, <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 20 Mar 2007 17:07:44 -0700
I just got confused on this one.
A Style Guide is a "guide" and not a law. Even CMOS allows for variations
from its guide to accommodate different departmental or managerial
preferences. Only an experienced writer should be entrusted with these
variations from my perspective, but if every writer changes the style, then
there is a fundamental problem that needs to be addressed.
Here's where I get confused. David, you mentioned that, "Writer after
writer had blithely overridden the document styles--and updating the
document to produce a consistent result was a veritable nightmare!" This is
a "document style" (in the old days it was "style sheet") issue and not a
"style guide" issue. Document styles should not be played with and should
be consistent across shared documents.
I just want to know where the argument is here, documents or guides?
> -----Original Message-----
> From: techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+lt34=csus -dot- edu -at- lists -dot- techwr-l -dot- com] On
> Behalf Of David Neeley
> Sent: Tuesday, March 20, 2007 9:40 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Re: Giving up on XML
> Among other things, Mike Starr observed:
> "Even the best style guide needs to be
> overridden once in a while. That's the value of an
> experienced writer."
> I disagree.
> For example, when I walked into a docs department at Nortel a few
> years ago, I encountered legacy documents that were updated every six
> months when a new software release was made for the telephone switch I
> was to document. Writer after writer had blithely overridden the
> document styles--and updating the document to produce a consistent
> result was a veritable nightmare!
> In my view, an "experienced" writer who is also a *professional*
> documentation person should be among the first to object when a style
> is being flaunted...at least with any document that must be issued
> with revisions over a period of time.
> It's really very simple--if the styles are not adequate, then *change
> the style* instead of overriding it!
> This is true of simple styles within the authoring tool as it is of
> more strict rules of XML. In fact, the difficulty of enforcing a
> reasonable and well-thought-out style set is a primary reason I don't
> care for Word for documentation (although the Nortel example was in
> Often, those who chafe at styles betray a poor understanding of the
> styles--which may be the fault of inadequate documentation for the
> style guide. When writers begin having trouble with any kind of style
> guide, I believe that the department management should inquire as to
> why, and be fully prepared to respond appropriately. However, I also
> believe that for the reasons I stated above, they should insist upon
> their styles being followed. The result is normally much more
> maintainable docs.
> Note, too, that I have several times advocated an approach in which
> the creation of content is divorced from style imposition. I still
> believe firmly it is far better for the bulk of the writers to spend
> their time on substantive content, leaving questions of style to those
> whose job it is to deal with them.
> Create HTML or Microsoft Word content and convert to Help
> file formats or
> printed documentation. Features include single source
> authoring, team authoring,
> Web-based technology, and PDF output.
> Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
> full Unicode support. Create help files, web-based help and PDF in up
> to 106 languages with Help & Manual: http://www.helpandmanual.com
> You are currently subscribed to TECHWR-L as lt34 -at- csus -dot- edu -dot-
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/techwhirl/ for more resources and info.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-