RE: Comparison of XML tools for writing documents

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.

I guess I should have said YMMV. ;)

------
Paul Nagai
Tsunami relief portal:
http://www.networkforgood.org/

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

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.



Follow-Ups:

Previous by Author: RE: Comparison of XML tools for writing documents
Next by Author: RE: Comparison of XML tools for writing documents
Previous by Thread: RE: Comparison of XML tools for writing documents
Next by Thread: RE: Comparison of XML tools for writing documents


What this post helpful? Share it with friends and colleagues:


Sponsored Ads