Re: Giving up on XML

Subject: Re: Giving up on XML
From: "David Neeley" <dbneeley -at- gmail -dot- com>
To: techwr-l -at- lists -dot- techwr-l -dot- com
Date: Wed, 21 Mar 2007 12:36:38 -0500

Lauren said my previous post confused her, then extended that thought:

"A Style Guide is a "guide" and not a law. ...

"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?"

The Nortel document styles were designed following their corporate
style guide. Thus, in overriding those styles and making changes in
individual documents, the writers were deviating from the style guide.

Of course it goes beyond that, in that on many occasions it was simply
lazy writers who failed to learn how to properly apply the various
styles (I used page numbering as one common example). They would
probably have used the "I'm too busy" excuse--yet the old saw was
fully applicable about how funny it is that people who lack the time
to do things right the first time seem always to find the time to
correct things over and over again.

In my view, a style guide for documentation should be matched with the
actual style sets in the authoring environment. Graphical examples of
documentation pages implementing each of these styles correctly--with
each one correctly and clearly labeled--should be a sine qua non for a
guide that is immediately and readily applicable.

As I have said before--and as you may grow tired of hearing me say
now--I believe the best approach is to separate creation of content
from creation of output styles. This might be in doing a two-stage
process by the same writers, or it may be done by having people
designated for dealing with output, the rest assigned to content

Given the appropriate tools, XML is a logical method for accomplishing
this goal.

Personally, I wish someone would get behind an effort to move Lyx
forward to being able to easily and fluidly accomplish this in an XML
world--or to create a similar tool for XML use. It is far more
difficult to monkey around with the styles using Lyx than it is just
to follow them. There are no convenient overrides; on the other hand,
the tool is simple to use for authoring.

Unfortunately, I am neither wealthy nor a programmer or I'd be taking
a shot at it myself!

I will be fascinated to see what the Madcap Software people
(publishers of Flare) do with their upcoming Blaze tool, which they
claim will solve many of the XML authoring conundra.


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 &amp; 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 &amp; Manual:

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -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 for more resources and info.


Previous by Author: One ding-a-ling too many? was: Questions about using Wingdings and Webdings
Next by Author: Re: Blogs for questions, blogs for answers
Previous by Thread: Re: Giving up on XML
Next by Thread: Re: Giving up on XML

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

Sponsored Ads