Is XML Spy good - and are there cheaper alternatives?

[daz_oldham]

Hi

I was just wondering what people thought of XML Spy and the XML Suite
that Alotva do and if it is worth shelling out for it. And, is it
cheap for what you get??

I am looking to be working with XML, XSD, XSLT so don't know if getting
a tool like this would make my life easier, or if Visual Studio 2005
will do what I need.

And, are there any cheaper alternatives?

Many thanks

Daz

 

[Andy Dingley]

I was just wondering what people thought of XML Spy

Used it on my last site (multi-seat site licence) and found our old
version of it to be attractive, but annoyingly buggy. On my current
site we use cheapskate open-source products, and find them to be far
better quality.

Good stuff with XML Spy:

- Nicely integrated XSLT workbench
- Easy introduction to XML Schema
- Really powerful project folder organisation.

Bad stuff with XML Spy:

- XML editor works wrongly. It creates paired tags when you create the
element, but it has no ability to close an existing start tag. jEdit is
vastly better.

- Rubbish XML validator. It gives you messages of the form "Diddly
squat somewhere near here" then leaves you to sort it out yourself.
Just when a "smart" XML editor is supposed to be at its most useful,
XMLSpy goes on a fag break. This is particularly irksome for beginners.

- Altova. Completely unhelpful over anything, including selling new
upgrade licences without buying full-price retail all over again. I'd
never deal with this compnay again, they were that unhelpful.

- Buggy. Prone to random "disappearing up its own root element"
crashes that lost your work.

- No printing. Looks great, but it crashes whenever you try to
actually print from it.

- Memory leaks

- Project folder organisation is powerful, but incomprehensible. You
really need to ask someone who has been using it for ages what the best
way to set things up is.

- Not much DTD support. I don't like them either, but I do still have
to work with the damned things.

- Obscure problems with working on XML documents referring to public
DTDs that either aren't downloadable, or aren't strictly accurate.
XMLSpy gets very confused here and there's nothing you can do about it.
It's not really a good answer to give BlueChipCo who are asking why
your code for their global integration product isn't working yet and
you tell them it's because their public DTD on the server at
head-office is an out-of-date version.


Overall I'd use it, but I don't like it, and I certainly wouldn't pay
money for it.

(Eclipse kicks ass)

 

[Bo]

I'm using the current version - 2006 sp2 - and find it very useful. I'm
at best a medium-level XSL-coder, doing jobs XML/XSL occasionally, and
XML Spy has helped me getting going. In particular, the debugger is
undispensable, as for any programming task. It's costly, but I have no
problems justifying the cost for my company. I've been able to focus on
the tasks at hand and be productive, even though it's a "left-hand" job
for me.

I haven't looked at alternatives. I tried the evaluation copy and it
convinced me to look no further. Particularly since I needed XSLT 2.0
features (or would be able to do some coding really much easier), and
XML Spy came right on time supporting them.

/Bo

 

[Stan Kitsis [MSFT]]

Daz,

If you are not looking for graphical tools, VS 2005 should handle your
needs. Here's an introduction article about Xml/Xslt/Xsd editing and Xslt
debugging:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnxmlnet/html/xmltools.asp

--
Stan Kitsis
Program Manager, XML Technologies
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[spiff]

Hi Andy!

I guess Daz has to try XMLSpy on his own because I don't share most of
your experiences with the product. Printing is of course working and
the Project funtionalities are really powerful and quite easy to set
up. Regarding the DTD support you have full OASIS Catalog support so
you can reference to public DTDs on your own PC.

What special DTD support would you like to have? Your XML instances
based on DTDs are validated and you get an Entry Helper on editing.
There is also an integrated entity support.

Compared to other products I think XMLSpy is pretty stable. Ok, I have
to admit that I mainly use XMLSpy.

Cheers

 

[daz_oldham]

Hey everyone - thanks for your input on this.

I think for the time being I am going to give Visual Studio a try, and
if I find I need the extra support that the graphical elements you get
from XML Spy, then I will try to get my company to purchase it for me.

Thanks again - I really appreaciate it.

Darren

 

[Andy Dingley]

I guess Daz has to try XMLSpy on his own because I don't share most of
your experiences with the product.

IMHO, the lack of auto-closure on elements with existing start tags is
enough of a reason on its own to use jEdit (or anything!) rather than
XMLSpy.

Printing is of course working

Printing was _not_ working. When a large corporate can't print from
XMLSpy (probably because they're running an obsolete version of XMLSpy)
and Altova's only response was "Buy new full-retail-cost licences for
everyone and _hope_ that might fix our bug", then that's not "working"
by my understanding of the term.

I'm sure printing probably does work for small Schemas under the latest
release of XMLSpy. But that didn't help me.

Project funtionalities are really powerful and quite easy to set up.

They're easy to set up, but only if you know how best to set them up.
An XMLSpy "greybeard" can configure things up usefully and effectively
in minutes, a beginner is likely to take one look at the complexity and
not even try. This is a tutorial issue, not a product function issue.

Regarding the DTD support you have full OASIS Catalog support so
you can reference to public DTDs on your own PC.

What special DTD support would you like to have?

My specific problem was with a large multi-component DTD (ecomm
integration) that was poorly hosted by its owner. Presumably it had
been set up by SGML wizards who had now left -- now the paths no longer
pointed between modules as they ought, and this confused XMLSpy
horribly (to the point of refusing to load documents).

The only way I could author was to have an XSLT transform added to my
publishing process. I worked on copies hacked up to use local DTD
copies, then re-wrote the doctypes when I released the code.

This wasn't "wrong" behaviour by XMLSpy, because there was an "error"
in the document and the tool was perfectly entitled to reject the
document as "invalid". However this is not the behaviour I want from a
good and useful tool -- my work consists of fixing stuff - the
documents and code I open _are_ invalid, that's why I have to open them
up and fix them. XMLSpy worked fine when everything was perfect, but it
was a disaster under pressure in the debuggering phase.

 

[Tony Lavinio]

You could also use Stylus Studio. See http://www.stylusstudio.com/

It is very conformant to standards, provides good cross-platform
support by letting you validate with several XSD validators including
XSV, Xerces-C++, Xerces-J and Saxonica.
http://www.stylusstudio.com/open_xsd_validation.html

It supports XSLT 1 and XSLT 2, across a variety of engines including
Saxon 8 -B and -SA, Saxon 6, Xalan, System.Xml from .Net, and more.
http://www.stylusstudio.com/xslt.html

It supports a variety of XQuery engines as well, including DDXQ
and Saxonica.
http://www.stylusstudio.com/xquery.html

You can cross-platform debug and profile code as well - you can even
debug Java extension functions by stepping and setting breakpoints
and going between XSLT and Java in the same call stack.

And we offer free support on the Stylus Studio Developer Network,
at http://www.stylusstudio.com/SSDN/

 

[Patrick J. Maloney]

Hi

I was just wondering what people thought of XML Spy and the XML Suite
that Alotva do and if it is worth shelling out for it. And, is it
cheap for what you get??

I am looking to be working with XML, XSD, XSLT so don't know if getting
a tool like this would make my life easier, or if Visual Studio 2005
will do what I need.

And, are there any cheaper alternatives?

Many thanks

Daz

Chiming in late, but I would look elsewhere. XML validator is buggy.
XPath evaluator is buggy.

 

[spiff]

Which validator and XPath engine is not buggy?

Regards

 

[bruce_phipps]

I'm an XML newbie. But is it true that a lot of the functionality of
products such as XMLSpy and/or Epic Editor can be replicated using open
source products if you are prepared to work from the command line now
and then?

PS: I'm not an open source evangelist here. It occured to me as a
newbie, that XMLSPy etc. provide a nice front-end to stuff which can be
done on the Linux command-line (xsltproc, xmllint for instance.)

bruce

 

[Joe Kesselman]

I'm an XML newbie. But is it true that a lot of the functionality of
products such as XMLSpy and/or Epic Editor can be replicated using open
source products if you are prepared to work from the command line now
and then?

So far, I've worked almost exclusively with open-source XML tools, with
the exception of the tools I'm actually developing... and even those
generally implement the standard APIs so the drivers could just as
easily be calling open-source code. Emacs (which has some syntax-assist
features suitable for XML), the Apache Xerces and Xalan packages (both
of which I've contributed significantly to, so I admit I'm biased),
Eclipse (which has some XML-specific plug-ins, though I haven't actually
tended to use them)

So I'd say the answer is "yes"... Which specific functionality are you
looking for?

 

[Andy Dingley]

I'm an XML newbie. But is it true that a lot of the functionality of
products such as XMLSpy and/or Epic Editor can be replicated using open
source products

Yes. Massively so. You don't even need to hit the command line, unless
you prefer it that way.

 

[Joe Kesselman]

Which validator and XPath engine is not buggy?

I'd call the Apache stuff "minimally" buggy (ie, about as good as
real-world code gets) -- and is still undergoing active development to
remove the remaining bugs as well as to add features, not to mention
being open-source so you can see the bug list and/or get involved in
that development effort yourself if so inclined. (Claimer: I and IBM
have contributed heavily to developing both the Xerces and Xalan
packages, and continue to do so, so I'm somewhat biased.)

 

[bruce_phipps]

So I'd say the answer is "yes"... Which specific functionality are you
looking for?

At the moment, to validate against a DTD and translate to HTML, PDF and
possibly other formats.

Bruce

 

[Joe Kesselman]

At the moment, to validate against a DTD

Any parser can do this; most come with a command-line sample, or you can
invoke the APIs. Apache Xerces, for example.

Recommendation: Migrate from DTDs to Schemas at your earliest
convenience. DTDs aren't namespace-aware, and most XML processing these
days does want to be able to handle namespaces properly.

and translate to HTML, PDF and possibly other formats.

Canonical solution is XSLT and/or XSL-FO tools. Apache Xalan and FOP,
for example. Of course you have to write the stylesheets to describe how
your particular XML is to be translated, or find stylesheets someone
else has written for that markup.


If you want a more interactive front-ends, as I say, I *think* there are
plug-ins for Eclipse that support

 

[Peter Flynn]

I'm an XML newbie. But is it true that a lot of the functionality of
products such as XMLSpy and/or Epic Editor can be replicated using open
source products if you are prepared to work from the command line now
and then?

Yes, absolutely.

PS: I'm not an open source evangelist here. It occured to me as a
newbie, that XMLSPy etc. provide a nice front-end to stuff which can be
done on the Linux command-line (xsltproc, xmllint for instance.)

Emacs with psgml-mode, xxml-mode, tdtd-mode, and xslide-mode
plus a copy of onsgmls and Saxon8 will get you probably 95%
of the functionality of any commercial editor/IDE...except
the synchronous typographical interface (what used to be
called WYSIWYG), which can be supplied by a browser or PDF
viewer window set to auto refresh. And you might not even
need to use the command-line, as most functions are either
menu items or keystrokes in the edit window. There are also
equivalent modes for working with RelaxNG instead of DTDs.

But if you absolutely, positively, must have Instant Textual
Gratification[tm] or you are working with end-users who would
be scared off by markup, then a synchronous typographical editor
is probably what you want. Spy and Epic are excellent of their
kind: there are dozens of others.

///Peter

 

[Stan R.]

So far, I've worked almost exclusively with open-source XML tools,
with the exception of the tools I'm actually developing... and even
those generally implement the standard APIs so the drivers could just
as easily be calling open-source code. Emacs (which has some
syntax-assist features suitable for XML), the Apache Xerces and Xalan
packages (both of which I've contributed significantly to, so I admit
I'm biased), Eclipse (which has some XML-specific plug-ins, though I
haven't actually tended to use them)

So I'd say the answer is "yes"... Which specific functionality are you
looking for?

What do you guys think about Oxygen? I find it to be a very useful, and
from what I've gathered from it thus far, IMHO it's far better than XML
Spy, whose newer versions have been a big let down for me.

 

[spiff]

Hi Stan!

I'm using XMLSpy a lot but your post made me curious about oXygen. So I
went to their site and looked around a little bit. I spent about 30
minutes there and found some more or less interesting points but except
support for some certain technologies (like RelaxNG) I didn't notice
something really special. But I like the extra dialog bars oXygen
offers. Especially the Outline, Stylesheet components and the Model
bar.

In general the functionalities offered in XMLSpy are more mature (like
the strange Schema editor in oXygen).

And on the other side I found quite a lot entries in the user forum
where users describe problems using oXygen with different Linux, Java
and Eclipse versions. I'm afraid maintaining Linux, Windows and MacOS
is not so easy and leads into usability issues.