RE: Evaluation of Arbortext and XMLSpy

[Chris Despopoulos <cud -at- telecable -dot- es>]

Ack!  I'm chiming in.  

First off, if anybody wants to pay me six figures to integrate Maker with Documentum, please let me know!  Come on out and visit - I'll buy you a ticket to Spain, and put you up for a week (I hope you like kids).

I don't have direct experience with the Documentum API.  If they use COM, then it's a no-brainer to get Documentum commands on the Maker menu.  But there are bigger issues than that, and I presume they relate to all XML systems.  You'll note that ArborText includes a dev environment roughly analogous to the FDK.  Care to guess why?  At some level, there is no horizontal solution to the SGML/XML problem - it's all vertical.  While much of high-tech has been commoditized, markup is still sufficiently esoteric that the world hasn't settled on a general use and/or description.  

Ok, back to Earth...  different products have different problems.  One known problem in Maker has to do with ID/IDREF attributes.  Maker generates these values, and can guarantee unique values within a document or a book.  But with doc mgmt you typically pick out small chunks of a book to edit them.  Within the system, Maker cannot guarantee unique values.  Explicitly setting ID vals for all element-creating actions (copy/paste, new elem, etc.) is non-trivial.  (I've done it - didn't get six figures.  Should I sue?)  

OTOH, the Native XML/Proprietary Format issue that has generated so much noise (and has inspired Adobe to Save As XML by default) is a red herring.  No system represents the markup internally as "native XML", and so if a product is more comfortable saving in a binary format or in XML, who cares as long as you can get valid XML when you want it?  Any bonehead FDK programmer could have trapped SAVE and turned it into Save As XML...  It so happens the bonehead who thought it worthwhile was an Adobe employee.

The point is, every "product" will have snags coming out of the box, and some are real while others are market smoke.  You need honest descriptions of what it takes to get what you want using the various systems.  You started out correctly by asking for testimonials from experienced users.  But I don't think you got the answers you wanted...  You need to  find people who are getting the results you want, and a chance to see how they do it.  Start with the output, and the legacy.  Who has similar end-points, and what lies between?  Remember, the devil is in the details.

And now I'll stir things up further by suggesting that if you already have Maker, maybe you should look at keeping it.  Why re-train and re-tool?  Make sure the re-tooling is actually less expensive than keeping on with Maker.  Well, you have one reason to re-tool - especially if you work for Apple.  That's a concern for the future of Maker.  But if Adobe maintains Maker (updates for Win 2008) for the next five years, then I believe you can get perfectly good service out if it for that time.  By then I certainly hope something will arise that leaps far ahead of Maker or Epic or XMLSpy.