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.
Subject:RE: Comparison of XML tools for writing documents From:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 20 Jan 2005 12:03:40 -0500
Wow. Need to catch up with e-mails sitting in my Draft folder.
I got side-tracked by a similar discussion on Framers and forgot about
this one.
bounce-techwr-l-106467 -at- lists -dot- techwr-l -dot- com wrote on 01/11/2005 01:33:34 PM:
> I intended to point out that Frame requires
> development time and money to create the EDDs and write
> rules in order to roundtrip XML. Epic does not since it
> works directly with XML.
But, as you state further on EPIC requires development of FOSIs (as well
as other work) to be functional. So to base a decision to go with Epic on
these grounds would be a decision based on a pointless and inaccurate
comparison.
Besides, FM can be set up very easily to roundtrip with XML. Nothing
Arbortext said in a sales presentation convinced me that Epic was any
better in that regard. Actually, unless you have to REALLY roundtrip the
content, the numerous FM features can be leveraged until the move to XML
is absolutely necessary.
> I would argue that FOSIs are costlier than FrameMaker
> templates by a long shot. I don't have enough experience
> with EDDs or write rules to factor them into a comparison.
Seeing as I taught myself EDD and template creation and maintenance with
supplied manuals, I can attest that the effort is not rocket science. I
actually found it quite simple when requirements are defined. However, the
only references for FOSIs and Epic setup I could find required
multi-thousand dollar training sessions from Arbortext.
(There's also the not so small issue of Epic requiring yearly licence
fees.)
> Our requirements specified that XML be stored in a CMS
> with library control (checkout/checkin). This implies
> every author have the ability import/export (in Frame)
> XML.
As easy as "Save as XML". Or very easily simplified with minimal scripting
or FDK work.
> With Epic, there's no import/export since it works
> with native XML.
Complete rubbish. Epic still needs to process the data into and out of the
editing environment. I don't see how it has much of an advantage in this
case. The only advantage is the perception of seamlessness as the "save as
XML" is the automatic default.
The only person who can claim they're working with "native" XML is someone
who writes and tags in ASCII text.
> Again, Frame does not integrate easily
> with CMSs. Yes, you can put Frame files into and take them
> out of any CMS outside of Frame, but pathing is tricky.
Seems Adobe didn't do a good enough job implementing and then promoting
the WebDAV capabilities. I guess some big client out there is using it as
I doubt it would have been implemented unless requested.
> Yes, you can modify Frame to add CMS capabilities to the
> menus. Epic provides an adapter for Documentum (the CMS we
> selected) that permits checkout/checkin (and other CMS
> functionality) from within the Epic client.
FrameBridge is available for Documentum. I attended a sales seminar
jointly run by Documentum and Adobe and the implementation seemed
excellent. Actually it was a day after Arbortext presented Epic to us (and
they were in attendance at the FM/Documentum show). They were particularly
evasive (or downright wrong if you had any FM experience) when asked how
what was presented by Adobe and Documentum was inferior or more difficult
than what they presented using EPIC/E3.
> As with generalizations, there is often a at least a
> kernel of truth underneath buzz words touted by sales people.
But the solution required to address that kernel of truth is not always
what the salesman is selling. And sometimes it may be A truth, but an
insignificant one.
> An authors way of thinking does change when shifting from
> authoring monolithic books to authoring chunks that are
> re-used across multiple books. Pick your buzz-words and
> vendors (or roll your own with free/share/open-ware), but
> this is true.
Which is only true if you continue to have your authors work on monolithic
books and documents. Create authoring templates and VOILA! FM is producing
strictly chunks. You have to make the same conceptual change to your
templates, storage, and workflow regardless of which authoring environment
you choose.
If you don't have a "chunked" DTD, structure, and storage arrangement for
EPIC, you'll be just as monolithic with Epic as you are currently with FM.
> Most of the customizations for Epic can be stored in a
> single location on the network accessed by all clients.
Actually, one of the HUGE advantages to FrameMaker IMO is that once you
have a structured template created, no-one really needs access to anything
other than a standard installation of FrameMaker. Only one machine needs
to be set up to create the XML files.
Give someone a installation CD for FM, a structured template, and a quick
guide on how to tag and they can be productive on any computer in the time
it takes to install and open a new document.
> Arbortext Command Language (ACL) is a scripting language
> through which tasks can be automated, menus/menu-items can
> be added/modified/removed, etc. Many of these things are
> possible with FrameMaker but at least some require third
> party tools and/or FDK-C/C++ skills.
Well, FrameScript IS a third party tool, but VERY inexpensive. And the FDK
is well documented and easy to work with. C programmers are easy to find,
and once familiar with FrameScript the transition to C and the FDK isn't
too painful.
FrameSLT and other products greatly enhance the functionality and
possibilities as well.
I think that the spectre of "third-party" scripting tools versus native
tools is one of those useless inconsequential kernels of truth.
Another unjust and insubstantial spectre is the idea of finding
"FDK-C/C++" skills. ACL programmers aren't exactly a dime a dozen either.
Or the "difficulty of EDDs". Compared to the downright ease of FOSIs?!?
Give me a break. (my frustration is not with you, but with the sales goons
and the managers who make decisions based not on substance but on the
buzzword/minute ratio.)
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.
