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 13:50:04 -0500
> (If is sometimes argued, that there is a gain in efficiency for
authors in
> using markup rather than WYSIWYG because it removes the need to worry
> about
> formatting. However, many document-oriented markup approaches simply
> replace
> the need for an explicit focus on document formatting with a need for
an
> explicit focus on document structure. The gain in efficiency may be
> dubious
> at best.)
Nonsense. What we are marking up mostly is semantics. The structural
components are extremely flexible and almost infinitely "nestable."
> But in both cases however, limits have been encountered because the
> creation
> and storage of information in documents and sub-document components
> imposes
> hard limits that cannot be overcome simply by moving from one
> document-oriented system to another.
Nonsense again. I have very little in the way of such limitations, and
I'm using fairly primitive techniques such as entities and Xincludes.
If I had an XML-aware CMS, I'd have no such limitations at all.
> This is where ease of processing comes in. If you create content in
> subject-oriented containers you will then need to transform it into
> document
> oriented container in order to deliver it to a customer. Using a
standard
> generalized markup language (of which both SGML and XML are instances)
to
> describe your subject-oriented markup language, will make it much
easier
> to
> write your formatting routines.
Exactly how is it easier to write your formatting routines when using
this approach requires you to write everything from scratch? At least
if you are using a standard markup, there are hordes of other folks all
contributing to the formatting scripts.
> In my view, a broad generic document-oriented markup language does not
> have
> enough advantages over today's DTP applications to be easily
justified. It
> may be competitive, but it isn't clearly superior.
Nonsense again. I've worked with document sets that fill a bookshelf
with these tools and done things that you can't approach outside of the
world of XML and SGML, such as automatically generate quick-reference
guides from large programming guides (and without resorting to marking
up components with metadata).
Let's take this out of the world of the theoretical. Exactly what have
you built with this approach?
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.
