RE: Comparison of XML tools for writing documents

[eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com]

bounce-techwr-l-106467 -at- lists -dot- techwr-l -dot- com wrote on 01/21/2005 02:32:59 AM:

> eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com wrote:

> Software that works with, and fully supports, native XML files - as
> opposed to software like Framemaker - does not "process" 
> the data into and out of the editing enviroment. They merely apply a 
> screen stylesheet on the XML data to make the editing more 
user-friendly. This does
> nothing to the XML files themselves.

Hmm. It may be semantics, but to me it seems that they're just doing what 
FM does with Read/write rules "on-the-fly" and there's no 
"work-in-progress" intermediate file format to save.

That has the disadvantage that any functionality you could gain from an 
application that isn't supported in XML can't be leveraged.

> The advantages are clear - no read/write rules, no re-
> mapping of Unicode to some propriety internal character encoding,  no 
> propriety internal element definitions (like Framemaker's EDD) etc.

Uhmm, there's no "propriety internal element definitions". An EDD is just 
a merged DTD and stylesheet. 

> It's a tad unfair -
> both to fully XML / Unicode compliant software and to "me-XML-too"
> software like FrameMaker - to compare the both.

I think Unicode support is probably the big Achilles heel of FrameMaker. 
The Frame character set and the limitations placed on some non-structured 
functionality (for example running headings are limited but their 
structured equivalent, elements that pull their information from other 
elements, are unlimited) are unfortunate holdovers of an old code base.

But, are the Unicode workarounds really that onerous? Or are the 
shortcomings based on the view that the information must ALWAYS be stored 
in xml and always be capable of "round-tripping" through multiple 
modifications?

> Framemaker may work very well for projects where issues like
> translation, automation, and integration to other systems 
> and workflows are not very important. But it is not the way to go if 
> these issues are important and one is very serious about setting up an 
XML 
> workflow. If this is the case, the way to go is solutions that fully 
> supports XMl/Unicode - e.g. Epic Editor, XMetal, XML Client etc.

Analyse the need for "translation, automation, and integration to other 
systems and workflows" and how your setup needs to work before believing 
the XML gurus. We were told at one time that the ONLY way was to build an 
SGML repository into which all work would be fed and then paper, pdf, and 
IEM output would be generated. The end result was it was much more 
efficient to have our internal information pass from FrameMaker to print, 
pdf, and the repository. The repository was then only for producing the 
IEM.

Even when multiple vendors are required, the repository approach was not 
necessary. Unless the workflow requires the integration of  multiple 
authors on single sources, the round-trip equation often doesn't add up.

Eric L. Dunn
Senior Technical Writer

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

WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l

Technical Communication Certificate online - Malaspina-University College, Canada. Online training in technical writing, software (FrameMaker, RoboHelp, Dreamweaver, Acrobat), document & web design, writing manuals, job search. www.pr.mala.bc.ca/tech_comm.htm for details.

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.