Re: XML-based Help Authoring tools for customized help

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

Sean Wheller wrote

> The whole point of working in XML is that the content and presentation
> layers are seperate.

Sean, you keep putting XML in a little box, and in so doing you make it both
more than it is and less than it is.

If you want to state the "whole point" of XML it is this: By defining a
common syntax for markup languages, XML allows you to develop a markup
language for any purpose you like, while still being able to use standard
parsers and standard structure validators. This greatly reduces the
programming effort needed to create and support a custom markup language.

You can make create an XML markup language for any purpose you like, and it
may have nothing to do with separating content and presentation. For
instance, OpenOffice is a suite of WYSIWYG office applications that uses a
collection of XML markup languages as a file format. It does not separate
content from presentation. For instance again, SOAP defines a protocol for
applications to communicate with each other over a network. It does not have
a presentation layer at all, so there is nothing to separate.

> XML is True Single-source and Frame is WYSIWYG.

XML is not true single source (however you define that). XML is a means for
designing tagging languages. Frame give good support for some kinds of
single sourcing (multiple media, conditional text) and not for others
(non-document oriented approaches). How well an XML format supports single
sourcing is 100% a function on how it is designed and 0% a function of it
being in XML. DocBook is no better at supporting single sourcing than Frame
is. The enemy of single sourcing is not WYSIWYG, it is document-oriented
thinking.

> The pradgim of authoring in a WYSIWYG environment and then exporting to
XML
> is broken and in my option should not be employed in any information
> development cycle where XML is employed as the storage format.

Again, you are putting tools before process. If this combination supports
the process that works best for a particular application then there is
nothing wrong with it. There is nothing inherently right or wrong about
tools and no problem was ever solved simply by adopting a tool. Tools exist
to support processes, and it is processes that solve problems. Documentation
problems do not go away just because you wrap tags around them.

> XML, as many
> have already said, is for exchange.

Again, no. What was said, if I remember correctly, was that *standards* are
for exchange. XML is for designing tagging languages. If you want to design
a tagging language to be adopted as a standard for exchange of some kind of
information, you can use XML. But it is the adoption of the standard that
makes the exchange possible, not the fact that it is in XML.

You can also use things other than XML to define standards and you can use
XML to define things that are not standards and are not used for exchange,
but are still useful.

XML is one way of doing a number of things. It is not the only way of doing
any of them.


> The point of using XML in the
> information development cycle is to avoid lock-in at the presentation
layer
> through the use of an open and standards based format. This format should
be
> transformable to any presentation (formatted) target.

Again no, for all the reason stated above. What you should say is that *one*
reason to use a document oriented markup language is to avoid lock-in at the
presentation layer.

There are many other approaches to managing content, other then the use of
document oriented tagging languages and any of them can be implemented using
XML, or without using XML.

Sean, in all of your posts on this topic you seems to be discussing a single
publishing system that happens to be based on XML and then you sound as if
you are claiming that:

A: This publishing system is XML and that all the virtues of XML are present
in this system.

B: The virtues of this system can only be implemented in XML and in no other
technology.

Neither of these things is true. XML is a useful tool that can be deployed
in many ways in many different kinds of publishing systems. However, it is
not the only way to implement any of those systems. You don't get any
publishing advantages just from the fact that you are using XML. You have to
implement a particular system to support a particular process. Your real win
comes from correctly defining an efficient process and successfully
implementing a robust and usable system to support that process.

The only advantages you get just from the fact that you are using XML are
the software development advantages listed above.

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.