Re: XML-based Help Authoring tools for customized help

["Mark Baker" <listsub -at- analecta -dot- com>]

Sean Wheller wrote:

> Take for example an OEM who sells to a channel. That
> channel may make
> valuable contributions to the content. Technically
> they are a seperate
> organization. Would you teach them the prepend
> language? This may or may not
> be posible. In which case, in order to receive back
> valuable contributions
> you would receive content in Docbook and transform
> back to the prepend
> language.

You are correct that one of the uses of a generic language like Docbook is
that it is useful for exchange. So yes, your options are

1. Teach your suppliers your topical markup language.
2. Transform their topical markup language into your topical markup
language. (Best practice in my view)
3. Transform their generic markup language into your topical markup
language.

These issues should be dealt with as part of contract negotiations.

> Can you give me the reference to where James has said
> this?

Probably not. I can check though.

> It seams to me that RNG is the future direction for
> Docbook. It will solve
> many of the problems we have been discussing.

We seem to have been discussing different problems. I have been discussing
the need to improve authoring by capturing information in a way that is:

* minimally invasive of the authoring process itself
* captures the richest semantics for the least effort
* catches problems as early as possible.

I'm not really sure what business problem you are trying to address. The
adoption of standards is, of course, the proper response to a number of
business problems. It isn't, however, the answer to all business problems
all of the time. Adopting a standard needs to be backed up with a practical
business objective, just like any other business decision. Similarly, when
you are adopting a standard, you need to make sure that you are adopting it
in the right place and in the right way as well as for the right reason. For
instance, just because you adopt a standard for excahnging information with
other does not mean that you need to do all your internal work in that
format. It only meant that you have to be able to send and recieve
information in that format.

> I see great
> benefit and simplicity from the adoption of standards.
> I don't really want
> to reinvent the wheel.

I agree that we should not reinvent the wheel, though there are times when
the wheel does need to be reinvented, if the current wheel is not up to the
job we are asking it to do. But I am not talking about reinventing the
wheel. I am talking about inventing something else that will work with the
wheel to create a more efficient process. If I was proposing to re-invent a
generic document description language, then I would be reinventing the
wheel. But I am proposing that people invent topical markup languages as a
data capture mechanism that is at another degree of separation from
presentation.

> I just want productive.

So do I. And in the quest for productivity, all avenues need to be explored.
The world of information development is vast and diverse. No one technique
or system is going to work most efficiently -- or even work at all -- for
all information developers everywhere.

I think that we would both see an advantage to the world if as much
information as possible was made available in standard and accessible
formats. One of the best hopes we have for getting as much material we can
into standard formats is not to try and push all authors to use those
standard formats -- we know they never will. But if we can present authors
with topical authoring interfaces that they find easy and intuitive to use,
and which also gives us data in a form that is readily transformable into
standard formats (potentially several different standard formats serving
different purposes) then we will be able to get a lot closer to the goal.

It is hard to push data uphill. It is also hard to get authors to work in
abstract data formats that do not readily match their experience. They
prefer tools that are easier to use. One such set of tools are word
processors. But word processors are downhill from the standard formats we
want. We will have to push the data uphill to get it into the standard form.
The alternative is to build a set of topical data capture tools that are
easy to use because they are simple and topical, but which are also uphill
of the standard format. (By uphill, I mean that they are more strictly
constrained and more semantically specific than the standard format.) If we
do this, then we can easily flow the data downhill to the standard format.
There is a potential for a huge win with this approach.


Mark Baker
Analecta Communications


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ROBOHELP FOR FRAMEMAKER TRIAL NOW AVAILABLE!

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.