Must-Have XML Tools

I recently tested a pair of XML tools that I would classify as the two best XML development environments on the market today: DataDirect technologies Stylus Studio 2007 XML Enterprise Suite and Altova XMLSpy 2007 Enterprise Edition. Overall, both of these tools are excellent products, and I intend to keep both packages available on my machine. Yes, I installed them on the same machine and they coexist peacefully. However, although both tools are excellent XML editors, they each have unique characteristics and show the influence of their original target audience. If your job involves constant XML work, you might find benefits to having both.

In reviewing these tools, I focused on several feature sets that each tool supports. XML editing is the primary function of each tool and a function that each tool performs admirably—so much so, in fact, that I don't think there are appreciable differences in capability. Next I looked at the tools' support for XQuery, a query language I generally try to avoid using. Each tool has a great set of XQuery-based features. Finally, I tested XML Web services support, one of the areas where I see real value for my long-term use of these tools outside of XML editing.

Stylus Studio 2007 XML Enterprise Suite

Installing Stylus Studio 2007 XML Enterprise Suite is simple. After installation, I found that Stylus Studio had mapped the XML extension to itself. The tool started and ran without problems; however, if you need assistance, Stylus Studio has a set of videos available online that are, in my opinion, extremely valuable. This was good, because as a .NET developer I initially felt a little out of place in the UI. My impression is that this editing environment seems to target those who work more with Java and other non-Microsoft tools, so I think the average Java developer will probably prefer the Stylus Studio environment. The tool doesn't integrate with Microsoft Visual Studio, and in fact it doesn't appear to directly integrate with anything. Although XMLSpy has integration features available, both packaged and as free downloads, Stylus Studio is a standalone environment.

I worked with the Stylus Studio editor, and as you would expect, it's able to read and validate Document Type Definition (DTD) and related namespace declarations. Although the Stylus Studio interface is set up with a focus on things such as links to the "Berkeley DB XML," with the online training assistance it was easy to get started and up to speed quickly. The behavior of such things as the Project display was slightly different from what I expected; however, in a short period of time I was comfortable with the Stylus Studio interface. By dragging and dropping elements from one XML document into another, I was able to quickly start creating an XQuery document. Overall, I found the support for XQuery impressive and liked the fact that Stylus Studio's open architecture let me select from one of several different XQuery processors. One thing that's consistent across the behavior and capabilities of this tool is its adherence to and support of open standards.

This support for open standards was evident when I looked at the tool's XML Web services capabilities. The Stylus Studio environment supports Universal Description, Discovery, and Integration (UDDI) as the basis for locating and manipulating Web services. The interface for working with the XML messages used by the Simple Object Access Protocol (SOAP) format lets you view the raw SOAP message as well as generate test messages to the server, as Figure 1 shows. The tool lets you connect to and send basic data elements to a remote service and view both your outbound messages and the reply messages from that service. However, unlike XMLSpy, the calls to a Web service happen automatically and you can't intercept and review the calling XML. This makes it somewhat more difficult to diagnose connection-related problems. In terms of making calls to a Web service, the tool provides an excellent environment that even supports integration with XQuery and, with a few additional steps, EDI.

One of Stylus Studio's feature sets is itssupport for industry-standard EDI. I workwith people who use EDI, and they felt thathaving Stylus Studio could help them if theydidn't already have Microsoft BizTalk Server.In terms of mapping new message formats,they felt Stylus Studio's EDI support was anexcellent feature and, in the right scenario,reason enough to select this tool.

One aspect that I didn't like was the product's Web page devoted to "gripes" about its competitor. Certainly the company can compare its product with the competition. However, repeating complaints about the competition from bloggers who have a history of supporting the company's product is, to put it politely, a distraction.

XMLSpy 2007 Enterprise Edition

Installing XMLSpy 2007 was also smooth. The installation software asked me if I wanted to assign XMLSpy as my default XML editor. After the installation and registration were complete, I opened the tool, which defaults to a sample project. The default project contains excellent examples of several key feature sets, including the Web Services Description Language (WSDL) editor, which Figure 2 shows, and the SQL debugger. However, although the interface layout is similar to Visual Studio, it was also a bit overwhelming.

When working with the XML editor initially, I wondered, "What's going on here?" In large part, my initial questions arose because the tool integrates elements such as the source XML document with its associated Extensible Style Language Transformations (XSLT). When these two items exist in the same project, the edit window for the source XML document will display the document's data based on the XSLT. For a new user, this integration can be a little disconcerting. However, as you explore and use the online training videos and achieve the productivity that such integration supports, what at first seemed like magic begins to make sense. In fact, after I got going with XMLSpy, I found its integration with XSLT an advantage over Stylus Studio.

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.

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.