• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6150
  • Last Modified:

XMLSPY vs XML Oxygen

I am looking for a review / comparison of XMLSPY vs. XML Oxygen.

Can anyone point me at some reviews or barring that offer their own reviews?

Thanks,
Howard
0
Howard Bash
Asked:
Howard Bash
  • 2
  • 2
2 Solutions
 
alain34Commented:
Hello hbash,

Have you considered this document. http://www.code-generator.com/Product_XmlStudio_ProductComparison.aspx
Personaly, I use XML Spy but an old version (2004).

Regards,

alain34
0
 
Geert BormansCommented:
well, where do I start...

I have never written a full review on this, but have been using Spy / Stylus Studio / Oxygen together for years.
About two years ago, I decided to get rid of XML Spy...
- it did not add any functionality to the other two packages
- Altova simple does not care about customers, even maintenance customers are often left in the dark
... so, I am biased.

Interesting to know is that I had an enterprise (full blown) version of all three, with maintenance (or software renewal, or whatever it is called by the different companies.

Spy has its own XSLT processor and schema parser... they both have too many flaws to be called standard. It is obvious that Spy is a tool built for the masses, and that they value the user interface's flashiness over the full compliance of their tools.
You can do development with eg. Saxon, by setting some parameters... I remeber it was quiet a hassle to get it to work

Oxygen10 now comes with both Saxon9B and Saxon9SA... and the Intell processors for free. So you really get a lot of value for money. Using Saxon 6,9B or 9SA or Xalan as an XSLT processor is no more effort then selecting from a drop down. Other processors come with the scenarios. If you want to do serious XSLT development, I would think Oxygen is the number one choice. There is an option of debugging modules of XSLT, so you can work outside the context of an importing module... pretty handy
I also like the clear three pane approach for testing transforms

Stylus is a very good second. Using scenarios it is pretty easy to used many different processors for XSLT
The interesting thing in Stylus Studio is the graphical XSLT developer. Drag and drop between to schemas to create the first step in an easy XSLT. I don't use that particular feature, but in some contexts it is neat.

Spy has an issue with its slow and buggy XSLT2 processor (the benchmark that used to be on their site simply is a bending of the thruth... it is just plain slow) Mainly if you are dealing with mixed content, the white-space bugs are a mess
I also am not too happy with way you can execute XSLTs, and look at/verifuy the result

Oxygen comes with a lot of neat tools, such as Trang for generating Schemas from XML documents, transforming different schema's to there alternative form, but some of these things are supported by Spy as well. If you are really into features, you should compare the features list on the respective websites.

Oxygen tends to be slow from time to time (it is all java). For speedy operations on large files (such as XPaths on large XML files) you should go for Stylus Studio. Spy is definitely not much faster than Oxygen.

Both Oxygen and Stylus have very good user support and well frequented user forums. Altova (Spy) simply ignore their userbase. Sales alone is important.

Well, I could rant forever.
Maybe you should telll us first what you want to do with the tool... I might come up with some other things too
cheers

Geert
 
0
 
kmartin7Commented:
I concur with Geert - XMLSpy is a (very) distant third. I have never liked it and probably never will.

I have not used some of the more recent versions of Oxygen, so I will not comment on it. Stylus Studio has a very good XSLT debugger and the XPath Query Editor is awesome. I have found their latest release (2008 R2) to be buggy, and have reported it. They said the issues will be fixed in the new 2009 release, due out next month.

kmartin7
0
 
Geert BormansCommented:
The XPath Query Editor of Stylus Studio has one minus, it is only XPath2.
If you are expecting XPath1, there might be issues, because of the explicit casting required
(that is one that I reported, I don't know if they changed it)
0
 
kmartin7Commented:
Our problems stemmed mostly with any query that searched all instances from root "//". Sometimes it would run, other times it crashed due to memory issues. For us, it is a much-needed tool.

I have only tried XPath2 syntax. Interesting...
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now