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:"Nagai, Paul" <pnagai -at- inovant -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Tue, 11 Jan 2005 10:33:34 -0800
>> 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.
I never suggested an *XML solution* was achievable without effort. 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.
> 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.
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.
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. With Epic, there's no import/export since it works with native XML. 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. 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.
>> 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.
As with generalizations, there is often a at least a kernel of truth underneath buzz words touted by sales people.
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.
> 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.
I agree with that. There are costs associated with that both up front and ongoing. Depending on requirements, that may be the way to go.
>> 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.
Most of the customizations for Epic can be stored in a single location on the network accessed by all clients. 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.
No way to tell what category the features you consider important fall into.
> 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.
I have no "answer" to this other than to state that while there were the usual "family squabbles" along the way, our authors participated in the requirements gathering, tool evaluation and selection, review of the detailed design, system testing, and final implementation.
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.
