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.
RE: XML-based Help Authoring tools for customized help
Subject:RE: XML-based Help Authoring tools for customized help From:"Bill Lawrence" <scribe -at- matrixplus -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 17 Dec 2003 10:36:41 -0500
> > For me if you customize docbook, it is not docbook anymore. If I
> > remember well, when I read about the standard, I also read that
> > although you can customize docbook, it is not advisable as the tools
> > would have to be customized to use the new elements or attributes
and
> > you loose the advantage of being able to send documents so that
> > everyone can read them through their preferred interface layout.
>
> It doesn't sound too helpful to me to make this an either-or question
-
> "either it is DocBook or it isn'†" After all, we're not arguing
> ideological purity here, we're talking about tools to get a job done.
>
> Given that DocBook explicitely was designed to be extendable, it seems
> inappropriate to call something that was derived from standard DocBook
> by the addition of a few elements or atttributes "not DocBook". At the
> same time, such derivatives are not any longer standard DocBook. It
> therefore seem most fitting to ascribe a degree of "DocBookness" to
any
> such derivatives.
>
> And whether or not it is "advisable" to extend DocBook surely must
> depend on the individual circumstances? After all, if you decide not
to
> extend DocBook, the alternative in many cases will be to create a
> completely new DTD _and_ completely new tools to work on it. In many
> cases this will mean a lot more work than extending DocBook, so why
> should the latter be inadvisable in such cases?
It's actually not too bad to customize it and customize the tools (at
least the Modular Docbook Stylesheets). The Modular Stylesheets were
designed with a customization layer in mind, and one simply needs to add
the additional XSLT code to that layer. You can then upgrade the
Stylesheets without worry.
The ideological purity comes into play when you're part of a consortium
with a lot of players adding to the doc. When I was with IBM and we
were contributing to products at the Open Software Foundation, keeping
Docbook pure helped ensure that all of the various players (and their
various tools) could use the documentation source without problems.
It's much less of an issue if you're not worried about other folks using
your source.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
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.
