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/11/2005 10:44:58 AM:
> Research we conducted a couple of years ago now, in front 
> of a project to move several documentation suites into XML
> and a Content Management System, found FrameMaker lacking 
> in the CMS-integration department.

Well, is Astoria still available? Documentum certainly is. And a WebDAV 
work environment could be implemented (although there seems to be issues).

> Further Frame did not work with and/or create and/or import native XML 
without 
> effort.

XML without effort? That's a pipe dream. To think that Epic is any less 
effort is a joke. FOSIs and setting up each installation is no less (or 
more) difficult than setting up templates and EDDs. In fact, I'd put the 
advantage to FM as once you have templates and EDDs for deliverables, ANY 
FrameMaker installation can produce required documents with only one being 
tightly monitored for export to XML.

> Finally, on a soft note, it perpetuated the format
> paradigm slowing the adoption of the content paradigm.

Buzz words oft touted by Abortext sales people. It's rubbish and 
completely meaningless.

You're only stuck in the "format paradigm" if your templates and formats 
only reflect look and feel and not structure and content definition. You 
can abandon the  "format paradigm" without even adopting structure if you 
name your styles correctly and make them hierarchical.

Once you have FM templates in place, you can beat recalcitrant writers 
into place with little effort. Just change the configuration files to 
remove access to the various formatting dialogs and options.

> There were other factors, of course, but those were the 
> high level drivers of the decision to work with Epic 
> instead.

> One post-implementation upside discovery about 
> our choice is that customizing and extending Epic is much 
> easier than FrameMaker.

Really? How so. I'd love to see real examples. The Arbortext guys failed 
to show me anything that couldn't easily be accomplished in FM. Indeed 
many of the required add-ons for Epic were built in to FM.

> I can't tell from your e-mail whether or not you have done
> this, but I think a move to XML-based documentation should
> be justified based on well understood requirements, 
> savings and/or enhanced capabilities resulting from such a
> move, etc. XML for XML's sake is a money pit.

That I agree with.

Ease your way towards structure, much like you can ease you way to single 
sourcing, by analysing your current data/content and redesigning your 
templates and gathering system to reflect structures and content. Then, 
when the time comes to structure the move will be painless.

If you can't get your team to work harmoniously with the concept of 
structure now, you won't be able to impose effectively it with a jump to 
an XML system without resistance and problems.

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

---
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.