This XSLT integration is an important feature, with only one drawback. The
display window for a document includes a bottom row of tabs, one of which is
labeled "Authentic." This button consistently failed because it was looking
for another Altova product, even on the examples provided by Altova. Altova
offers a suite of products that are all associated with XML-type activities.
The company sells XMLSpy as part of these packages, which include features such
as Style Sheet editing. As I used XMLSpy, I encountered several instances in
which I clicked buttons that essentially told me I needed another product to
make the feature that I was trying to use actually work. The Authentic tab is
just one example; the same thing occurs when you open the DTD/ Schema menu and
the menu option offers to install a trial version of MapForce. Altova
needs to follow the Visual Studio model, which just omits unavailable features,
and remove such messages.
With regard to XQuery, one of the features I really liked was the way XMLSpy's
XQuery debugging worked. The fact that I could stop an XQuery execution in process
and review all the variables was great. I discovered that Altova uses its own
customer processor for XQuery. Although I'm not a big XQuery user, this practice
strikes me as a potential risk if I'm considering developing an XQuery query
that will eventually run in another environment. Working against a custom processor
means that my XQuery might not act exactly the same in the target environment,
and debugging any problems at that point would become difficult and time consuming.
Although the risks might not be a problem for a developer looking to integrate
with .NET and related Microsoft technology only, it could be a significant drawback
in a heterogeneous environment.
As for XML Web services, I was impressed with XMLSpy's editing environment.
The graphical layout of the SOAP message structure helped me visualize the data
that was being transferred. Although the debugger is powerful, by default it's
disabled so if you jump in without getting more information related to enabling
this debugger you might have a problem. However, after you enable the
debugger, it actually intercepts the outbound request and inbound response
to your Web service so that you can see what's actually being sent across the
wire. After I got accustomed to the environment, I found XMLSpy to be an excellent
tool.
Finally, one feature that really appealed to me about XMLSpy was its integration
with Microsoft Internet Explorer (IE). XMLSpy let me right-click and open the
HTML source for a Web page within its editing environment. I know that hundreds,
if not thousands, of other developers will scream in disgust at the very idea.
But for each of them, another developer will say, "Hey, that's cool." To me,
this feature helps illustrate the difference in approach between these two tools.
Stylus Studio is a standalone product that focuses on playing in its own sandbox.
XMLSpy however, plays well with others: It follows a more integrated
method of leveraging the system to provide a variety of features that a user
might find valuable.
| ALTOVA XMLSPY 2007 ENTERPRISE
EDITION
PROS: Supports Microsoft Visual Studio, .NET, and Eclipse Web services
platforms; supports Java, C++, and C# code generation; offers Web service
design and debugging tools
CONS: Initial experience with UI can be overwhelming; some features
such as Web service debugging can be challenging at first use; features
that require other Altova products aren't hidden or disabled
RATING: 4 out of 5
PRICE: Single user license as tested lists at $999 RECOMMENDATION:
Choose this tool if you work exclusively with Visual Studio or if
you do the majority of your work with .NET.
CONTACT: Altova • 978-816-1600 • http://
www.altova.com |
Reviewing the Pros and Cons
Both products are excellent tools, and each has a feature list that's huge.
You'll probably make your choice based on specific technical requirements or
depending on the tool's approach to problem solving. Although each tool has
unique features, the tools overlap in most areas.
If you need to use one of these tools because it has a specific feature such
as EDI support or Visual Studio integration, but it's not a tool that fits your
style, let yourself get acclimated to that environment. As someone who uses
Visual Studio almost every day, I felt that XMLSpy was a companion environment.
However, I was impressed by how comfortable I felt working within Stylus Studio
and how productive I was when using it.
I want to work in both of these tools' environments because each has some unique
characteristics. For example, even though each supports XML Web services, each
does so with a different feature set—Stylus Studio provides what I consider
to be a better environment for exploring external Web services whereas XMLSpy
provides a richer environment for developing such services locally.
Thus my plan is to keep both tools available, although I set XMLSpy to be my
default XML editing environment because I like the general layout and display
of the editor when working with XML and because of the tool's integration with
Visual Studio and .NET. However, I don't want to surrender such features as
Stylus Studio's support for open standards or its support for UDDI lookup of
Web services; someday I might be involved in an EDI project and I would want
to be able to use Stylus Studio in that case. In fact, if I spent a large percentage
of my time working with nonMicrosoft tools, I could easily see myself setting
Stylus Studio as my default handler for XML file extensions. As a result, it
seems appropriate to designate both of these tools as earning an Editor's Choice
award. You might not have the option of using both, but either one of these
tools could be the right tool for you.
End of Article
Prev. page
1
[2]
next page -->
