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: Thu, 20 Jan 2005 10:51:36 -0800


[ha! I just accidentally sent this to framers ;) doh!]

Before I address any specifics within your note, allow me to stipulate the following:

An Arbortext solution an Enterprise solution. To speak plainly, it will cost a lot of money. I would be surprised to find an Arbortext solution that didn't end up in the six figure range NOT counting the internal resources of the customer. FOSI development and maintenance, if required, very well may be an ongoing cost (that is, it is never internallized by the customer). All Arbortext software licenses require annual maintenance fees. Well, if you want support and/or upgrades. I don't think Epic stops working if you stop paying, but you don't get upgrades or support.


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.

Of course. I do not think I suggested anyone do so.

Everyone: Please do not base six-figure decisions and multi-year projects on a single paragraph of any one of my e-mails. Phew! Millions saved!

But seriously, raising the FOSI cost issue here distracts from my original point: Creating EDDs and write rules in order to round trip XML (presumably between Frame and some other application that will likely have requirements on that XML) takes time and money. I don't doubt that FrameMaker can Save As XML. I suspect, however, that if your XML must be handled by multiple applications, you will have to spend some time understanding FrameMaker's XML limitations, tuning EDDs, write rules, and your other XML application(s), and maybe some creating/using something (XSLT?) in between. Plan for it.


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

Yes, but paired with the requirement I mentioned elsewhere (authoring environment-CMS-integration), Save As XML nor scripting were satisfactory.


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

Provide Epic with a DTD and a matching XML file, and it can open, edit, and save that XML file. My understanding is that FrameMaker would require EDDs and write rules to be able to do that. Am I wrong?


> The only person who can claim they're working with "native"
> XML is someone who writes and tags in ASCII text.

Maybe I have misused language somewhere, but there is a class of tools that I would say work with native XML: XMLSpy, Epic, etc. The open, edit, validate, and write out XML based on the XML itself and a DTD. FrameMaker is not in that class.

A powerful text editor (I like Textpad) is a valuable tool in the toolbox of every person supporting an XML environment. Don't, however, fail to distinguish between modifying XML files with a text editor and editing XML. Maybe I'm making something up here, but there is a difference. Using your text editor *you* are responsible for the validity of that file when you are done. With an XML editor, *it* is responsible for validity. I'm not sure that I would say editing XML *files* with a text editor is working with native XML in the context of an "XML editor discussion." But hey, that's semantics ...


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

Do you mean FrameLink?
http://www.datalogics.com/framelink.asp

At the time we did our research both Adobe and Documentum reps were lukewarm, at best, about this product. FrameLink's own website at that time was at least a whole FrameMaker version behind. Their site currently refers to Frame 6 and Documentum 4.

If you really did mean FrameBridge, please provide a reference. Searches on Documentum, Adobe, and Google don't turn anything up.


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

I don't remember exactly how this conversation drifted into the discussion of chunk-authoring. My original point was, I thought, that I believe that the formatting feedback provided by FrameMaker slows the adoption of a "think content" mindset. I accept that your experience and the experience of authors you work with may be different.


> I think that the spectre of "third-party" scripting tools versus
> native tools is one of those useless inconsequential kernels of truth.

Fair enough. I would suggest, however, that there is an upside to having the scripting language owned, upgraded, and supported by the same vendor producing the editor. That upside comes at a cost. See previous stipulations.


> 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?!?

ACL scripting is fairly straightforward. Anyone comfortable with javascript will be able to maintain, if not create, most of the customizations required. This is not to say that ACL is not powerful or that extremely complex applications can't be created within it ... just that there is a lot of low hanging customization fruit accessible to ACL.

I have also developed FDK-c/c++ customizations for Frame (although it has been a while ... they were for v5.5.6). ACL was easier for me to pick up than the FDK stuff. Admittedly, though, the c/c++ required to do FDK work is at the lower end of c/c++ skills.

FOSI work is in a class by itself. Expensive. Complicated. Twitchy. And, not a useful skillset outside of the Arbortext world. That said, newer Arbortext tools (Styler) are addressing this problem. Also, Epic is not tied to FOSI for print stylesheets. XSL/FO is also supported.

Can spectres be unjust? I'd say they were unholy. Someone considering migrating to an XML environment should consider where they want to spend how much money for what deliverables AND their available resources, skillsets, standards, etc. If you've got spectres, call a spectre-buster.


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

Hey, some of my best friends are sales people (and managers)! Arbortext is as guilty as any other software company of trying to tell their story and convert listeners to customers. If you're in the market to replace FrameMaker (structured or otherwise) with an XML editor, you've got to talk with Arbortext. You don't have to buy their story, though. Nor should you buy ANY XML story unless you've got a story of your own that has already convinced someone with money that you've got something to gain (or stop losing) by making that change.

Hopefully the Eric and Paul show has been illustrative for all you kids out there! Hey Eric, maybe we could turn this into a road show. Get invited to conferences. Wined and dined. Which of us gets to be Dan Aykroyd! ;)

Cheers, all.

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

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.



Follow-Ups:

Previous by Author: RE: Comparison of XML tools for writing documents
Next by Author: Re: slow writer
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