Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Evaluation of Arbortext and XMLSpy

2 views
Skip to first unread message

Subash

unread,
May 10, 2004, 3:46:05 AM5/10/04
to TECHWR-L, sanit...@hotmail.com

Attached is a query from Anitha. Please mark a copy of your replies to
sanit...@hotmail.com.

----------------------------

Hi All,

I would like to have comments from those who have hand-on experience of
Arbortext and XMLSpy. I am looking for answers to the following
questions:

- In an enterprise environment, which is the best tool to edit xml files?
- Which of these tools is more effective in terms of generating a valid
xml file out of a valid FM sgml file?
- Learning curve of these tools
- Graphics capability of these tools
- Usability of these tools
- Productivity potential of these tools
- Which of these two tools is cheaper?


Any other useful information regarding these two tools is highly
appreciated.

It would be great if you could respond by tomorrow.

Thanks in advance,
Anitha

----------------------------


--
Subash Babu
suba...@speedpost.net

--
http://www.fastmail.fm - A no graphics, no pop-ups email service

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

SEE THE ALL NEW ROBOHELP X5 IN ACTION: RoboHelp X5 is a giant leap forward
in Help authoring technology, featuring Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more! http://www.macromedia.com/go/techwrldemo

|From a single set of Word documents, create online Help and printed
documentation with ComponentOne Doc-To-Help 7 Professional, a new yearly
subscription service offering free updates and upgrades, support, and more.
http://www.doctohelp.com

---
You are currently subscribed to techwr-l as:
tech...@gts.org
To unsubscribe send a blank email to leave-tech...@lists.raycomm.com
Send administrative questions to ej...@raycomm.com. Visit
http://www.raycomm.com/techwhirl/ for more resources and info.


eric...@ca.transport.bombardier.com

unread,
May 10, 2004, 9:33:04 AM5/10/04
to TECHWR-L, sanit...@hotmail.com, TECHWR-L

bounce-tech...@lists.raycomm.com wrote on 05/10/2004 03:46:05 AM:
| - Which of these tools is more effective in terms of
| generating a valid xml file out of a valid FM sgml file?

You'd have to give more details about your XML needs. What do you need
XMLSpy or Arbortext to do?
You should be able to create valid XML straight out of FM7.0/7.1. I found
that the Arbortext salesfolk made mountains out of mole hills trying to
shoot down FM workflows while boost their equally convoluted systems.

If you have valid SGML and just want to make valid XML you could even use
s2x from James Clark's SP package. And that's free. No need to give the
hucksters your hard earned cash. ;)

Eric L. Dunn
Senior Technical Writer

Nagai, Paul

unread,
May 10, 2004, 11:07:06 AM5/10/04
to TECHWR-L, sanit...@hotmail.com

| - In an enterprise environment, which is the best tool to edit xml files?

Not possible to answer without understanding your requirements. Composition (printing, exporting html, etc.) requirements may be the most important component of that question.


| - Which of these tools is more effective in terms of generating a valid
| xml file out of a valid FM sgml file?

I can't help there other than to say that Arbortext has a conversion tool, Interchange, that may facilitate this. It is a separate module than the editor, Epic.


| - Learning curve of these tools

While not an XMLSpy user (I've dabbled, though), I'd say they are probably about the same. And if you're coming from an unstructured environment (which it appears you're not), the learning curve is steeper on structure than the tool.


| - Graphics capability of these tools

To my knowledge, neither tool has the ability to do anything but present graphics created elsewhere. You can find Epic's list of supported formats on arbortext.com.


| - Usability of these tools

Essentially the same answer as to learning curve.


| - Productivity potential of these tools

Generally speaking, I would say that any productivity potential probably lies in the systems that can be built around these tools, not necessarily in the tools themselves. For example, given an experienced author, editing productivity with a bit of XML won't be significantly different in Epic, XMLSpy, or FM. However, placing that bit within a content management system (Documentum, for example) that is accessible from within the tool itself (Epic) can make a HUGE bit of difference. (I don't know whether XMLSpy integrates with any CMSs. Structured Frame doesn't really integrate with Documentum. Beyond that I can't make any observations.)


| - Which of these two tools is cheaper?

I'm pretty sure if you compare a single user license, XMLSpy. However, most purchases are in greater volume and discounts may apply. Further, you'll need to price your entire "solution" including the composition piece, CMS (if applicable), etc. etc. etc. Don't forget consulting services (or internal development costs). If applicable.

------
Paul Nagai

eric...@ca.transport.bombardier.com

unread,
May 10, 2004, 11:25:02 AM5/10/04
to TECHWR-L, sanit...@hotmail.com, TECHWR-L

"Nagai, Paul" <pna...@inovant.com> wrote on 05/10/2004 11:07:06 AM:
| Structured Frame doesn't really integrate with Documentum.

Not sure the Adobe or Documentum people would agree with you on that. The
last travelling road show I went to here in Montreal was a joint
presentation of structured FM to create XML and its integration with a
Documentum workflow.

Eric L. Dunn
Senior Technical Writer

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

David Knopf

unread,
May 10, 2004, 11:42:31 AM5/10/04
to TECHWR-L, TECHWR-L, sanit...@hotmail.com

Subash wrote:

|I would like to have comments from those who have hand-on experience of
|Arbortext and XMLSpy. I am looking for answers to the following
|questions:
|
|- In an enterprise environment, which is the best tool to edit xml files?
|- Which of these tools is more effective in terms of generating a valid
|xml file out of a valid FM sgml file?
|
|

You do not need either of these tools to produce valid XML from
Structured FrameMaker. You can do this with FrameMaker itself.

Regards,


--

*David Knopf ~ Knopf Online ~ San Francisco*
mailto:da...@knopf.com ~ http://www.knopf.com

Consulting & Training for Technical Communicators
RoboHelp ~ FrameMaker ~ WebWorks ~ Structured Authoring ~ XML
WebWorks Publisher Certified ~ Adobe Certified Expert: FrameMaker
Member, JavaHelp 2.0 Expert Group
Moderator, HATT, wwp-users & Techshoret

Nagai, Paul

unread,
May 10, 2004, 12:17:34 PM5/10/04
to TECHWR-L, sanit...@hotmail.com

| "Nagai, Paul" <pna...@inovant.com> wrote on 05/10/2004 11:07:06 AM:
| > Structured Frame doesn't really integrate with Documentum.
|
| Not sure the Adobe or Documentum people would agree with you on that. The
| last travelling road show I went to here in Montreal was a joint
| presentation of structured FM to create XML and its integration with a
| Documentum workflow.

Documentum workflows can "integrate" with any software, of course. But in the same way Windows Explorer can. That is, it can know certain content is associated with this application or that one.

Epic, however, integrates with Documentum through custom menus accessible within Epic itself. On accessing content within a Documentum repository, Epic can perform a variety of functions on the content before presenting it to the user. Or before returning it to the repository when an author is done with the content.

Frame doesn't do that. Or didn't when we did our analysis a year and a half ago. Adobe and Documentum both acknowledge the existence of FrameLink:
http://www.datalogics.com/framelink.asp

But neither company gave me a warm, comfortable feeling about this product. A quick review of their website finds that their What's New PDF was authored in 2001 and mentions FM6 and Documentum 4i.

All that said, it is entirely possible that there is something new in the Adobe/Documentum partnership pipeline or product suite I am not aware of. If there is deeper integration than I've described, I'd like to know about it. If only for not making a fool of myself in the future ;)

------
Paul Nagai

technicoid

unread,
May 10, 2004, 12:22:38 PM5/10/04
to TECHWR-L, sanit...@hotmail.com

Hi, Paul.

Like many Adobe products, extensions like that aren't provided by Adobe,
but the products include APIs to all other developers to create them. No
doubt the FDK can be used to this end. Maybe Chris Despopoulos can chime
in and shed some light on what the FDK can enable in such an
environment.

Bill
techn...@cableone.net

eric...@ca.transport.bombardier.com

unread,
May 10, 2004, 1:20:06 PM5/10/04
to TECHWR-L, sanit...@hotmail.com, TECHWR-L

"technicoid" <techn...@cableone.net> wrote on 05/10/2004 12:22:38 PM:
| No doubt the FDK can be used to this end.

Ah yes. The wonderful choice of whether to spend six figures on software
and training or to spend six figures on in-house development. ;)
I think the discussion about Documentum is a little above the intent of
the initial inquiry.
I would hazard the guess that the perceived requirement for additional
tools may indeed be due to not understanding the powers and possibilities
that are present in the current workflow. It may even be that it's because
someone in the loop has believed the marketing wonk or Alpha programmer
priest that an XML workflow has to be pure or it's unworthy.
But, if there are requirements that FrameMaker can't handle I'd lean
towards XMLSpy. Just seems to me that they're more towards supporting web
and XML workflows and less about trying to sell you their training,
support, and solutions. Perhaps that's only because I was subjected to an
Arbortext sales pitch. But, XMLSpy has FREE tools to edit XML (Authentic)
whereas with Arbortext you have to pay for the tool and pay annual
maintenance fees.


Eric L. Dunn
Senior Technical Writer

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

Nagai, Paul

unread,
May 10, 2004, 4:00:53 PM5/10/04
to TECHWR-L, sanit...@hotmail.com

| "technicoid" <techn...@cableone.net> wrote on 05/10/2004 12:22:38 PM:
| > No doubt the FDK can be used to this end.
|
| Ah yes. The wonderful choice of whether to spend six figures on software
| and training or to spend six figures on in-house development. ;)

And/or spend six figures on year 1's consulting fees.


| I think the discussion about Documentum is a little above the intent of
| the initial inquiry.
| I would hazard the guess that the perceived requirement for additional
| tools may indeed be due to not understanding the powers and possibilities
| that are present in the current workflow.

This and your other guesses are all valid. Tossing around the term, "Enterprise," however, will cost you money in the end no matter what toolset or vendor you choose.

------
Paul Nagai

Chris Despopoulos

unread,
May 11, 2004, 11:23:43 AM5/11/04
to TECHWR-L

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.


|Maybe Chris Despopoulos can chime
|in and shed some light on what the FDK can enable in such an

and

|Ah yes. The wonderful choice of whether to spend six figures on software
|and training or to spend six figures on in-house development. ;)

|I think the discussion about Documentum is a little above the intent of
|the initial inquiry.

0 new messages