XSLT Test Tool


This tool was created for a number of reasons:

I wanted this to allow me to be productive right away, so I didn't spend much time coding it.  The code is very simple.  The Visual Basic source is included and you can do whatever you want with it.  It currently works with MSXML (you need to update with the March 2000 version of the MSXML parser or newer), Saxon, Xalan, Oracle XSL, Sablotron, Xt, Unicorn, Napa, 4XSLT and Instant Saxon.  This tool will work fine with whatever processors you have installed; you do not need to install all of these processors to use it.

This tool was not created to be a full-blown XSLT editor for Windows.  Some tools that have been recommended to augment this tool are listed here:

[Click here for a screen shot.  Note that the screen picture (76k) is a larger download than the actual program!]


[There is a little self-extracting install utility that I wrote which will download and install this tool, all of the other XSLT processors, and the MSXML3 processor and documentation.  It is fairly simple and reliable.  If it does not work for you, please proceed with manual instructions.]

Just download the XSLT Test Tool distribution (125 kb) and unzip it to some directory.  I only wrote it for Windows.  You might need the free VB6 Runtime DLL in your system directory to run this.  You need to install any processors which you wish to use as well.  For non-MSXML processors, the tool assumes that you are running from c:\saxon, c:\xalan, c:\oraxml, c:\xt, c:\sablotron, c:\unicorn, c:\napa, c:\python20\scripts (4XSLT) and c:\insax.  This is obviously going to be different for most people in most cases, so I made it easy to tell the tool where your parser is located.  Just find the directory where you unzipped this tool, and load the desired batch file (saxon.bat, xalan.bat, oracle.bat, xt.bat, sablotron.bat, unicorn.bat, napa.bat, 4xslt.bat, or insax.bat) into a text editor like notepad.  Change the path after the -classpath to point to the location of your .jar file.  Some processors need you to specify the location of an XML parser -- in these cases, the batch file will have a second .jar file specified after the first, separated by a semicolon.  Most of the XSLT processors allow you to switch between XML parsers; see the home pages of the parsers to see how.  Additionally, note that the batch files for this tool explicitly include the classpath in the java invocation.  I have found it to be much safer if you keep the classpath of one processor isolated from another, so this approach is probably wisest if you add other processors.

Note: if you run the test tool and get an error resembling "control not found", there is a possibility that the new text control is not registered on your machine.  (I have never had to register it, I am just adding this hint preemptively in case it actually turns out to be a problem).  To register the control, go to the directory where you installed the tool and type regsvr32 richtxt32.ocx.

Finally, if you want to be able to launch the XML/XSLT online help from this GUI, you will need to have installed your XML SDK to the default location (<C:\Program Files\Microsoft XML Parser SDK\Docs\xmlsdk30.chm>).

Using the Tool

To try some XSLT transforms:

  1. Launch the tool (xslt.exe)
  2. Type an XSLT transform into the top-left textbox
  3. Type some XML into the bottom-left textbox
  4. From the "Options" menu, select the XSLT processor that you wish to use (MSXML is default)
  5. Double-click the frame between right and left, or select "Process|XForm" from the menu

The file menu allows you to save or load your work.  If you would like to start with a sample right away, you can load wines.xslt and wines.xml from the directory where you installed this tool.  Select "Process|View in Browser" if you want to view the output as HTML in a web browser.  The tool always remembers the last directory from which you were working.

If you would like to validate your input data when loading, make sure that "Options|Validate Input" is checked.  You can deselect this option if you are using non-XML data on input.  When you run from the command line, validation is disabled.

Adding XSLT Elements

If you right-click anywhere in the text window, you should get a list of XSLT elements for insertion.  If the XSLT element you choose is normally enclosing something, the element begin and closing tags will be inserted surrounding whatever you have highlighted in the editor.  If you wish to modify the behavior or add any elements, look at commands.txt in the directory where you installed the tool.

Pretty Format

You can right-click in the XSLT or XML windows to "Pretty" your data by indenting.  The indents are accomplished through the use of the file pretty.xslt in the program's install directory, so you can modify that stylesheet if you want different behavior when prettying.  The stylesheet pretty.xslt was created by Nikolai Grigoriev of RenderX.  Eric van der Vlist and Martin Naughton have both posted alternate pretty formatting stylesheets to xsl-list, which should be availabe soon in the archives.

XPath Query

Select Process|XPath from the menu, and you can type in any XPath expression.  The XPath will be evaluated against the XML in your XML text box and the output will be shown in the result window.  For example, you could try //node()[@name="merlot"] against the demonstration wines.xml file that comes with the tool.

Using from the Command Line

You can launch this tool from the command line with the following syntax:

xslt.exe xform_filename input_filename output_filename [P]

Where P is an optional parameter specifying which processor to use (M=MSXML, S=Saxon, X=Xalan, O=Oracle, T=Xt, B=Sablotron).  MSXML is the default.  Also, realize that all of the other processors have their own command-line syntax, which will be much more efficient to use; the P parameter will be useful in only a few situations.

The tool mentioned at http://www.netcrucible.com/xslt/msxml-faq.htm#Q12 is faster for MSXML3, supports Unicode, etc.

Finding Differences in Output

Some reasons you might want to compare output of multiple transforms could be:

The easiest way to do this is to just run the transforms and manually compare.  In some situations, though, it will be useful to do more sophisticated comparison by following these steps:

  1. Run your first transform as normal, leaving the results in the output textbox.
  2. Change your XSLT, XML, or select a different processor ("Options" menu)
  3. Now, instead of double-clicking or selecting "Process|XForm", choose "Process|XForm and Compare Current" from the menu
  4. The tool will transform using the new settings, then show you the output of comparison between the new and previous transforms

By default, the tool uses windiff to compare the outputs, so if you do not have windiff, you will need to configure a different comparison tool.  You can easily change the comparison tool.  Simply go to the directory where you unzipped this tool, locate compare.bat, and load it into a text editor such as notepad.  Notice that it just launches windiff against the files tmpprev.dat and tmpnew.dat, which are created automatically for you when you invoke a comparison.  Just change compare.bat to use the comparison tool you desire.  If you use a text-based comparision tool (such as MKS toolkit "diff"), you should add the pause statement to the end of the batch file so the user will be able to view the results before the shell window closes.  Besides choosing a comparison tool other than windiff, there are some more reasons you might wish to edit compare.bat:

Finally, if you make any useful changes to this tool or the accompanying batch files, feel free to e-mail me and I will put them up here for others to share (giving you credit, of course!).  Also, if there is something bizarre or stupid about the way I put this together and you feel that it will cause grief to many people who use the tool, please tell me so I can fix it!


Joshua Allen <joshuaa@netcrucible.com>
Last Update: 12/27/2000

Known Bugs:

If you use a relative URI on an xsl:include, this tool may assume that the URI is relative to the directory where the tool is located rather than the directory where your XML file is stored.  This will be fixed eventually, in the meantime you can workaround by using absolute URIs.

Change History:

12/27/2000 - Pointed to the better command-line tool
12/4/2000 - Modified to remember which XSLT processor you were using between sessions
12/4/2000 - Added Napa, Unicorn, and 4XSLT processors
12/4/2000 - Fixed bug with pretty formatting
12/4/2000 - Fixed bug where minimizing would cause error
10/7/2000 - Added pretty formatting; thanks Nokolai Grigoriev!
10/7/2000 - Now remembers your working directory between sessions
10/7/2000 - XPath test added
10/4/2000 - Added ability to insert XSLT elements automatically
10/4/2000 - Added support for Sablotron
10/4/2000 - Text controls now can handle more than 64k files
8/2/2000 - Now default to preserveWhitespace, optionally disabled on menu
7/28/2000 - Input boxes now resize with form
7/28/2000 - Fixed bug with working directory being changed
7/28/2000 - Added link to automatic download/installer for all XSLT processors.
7/19/2000 - Added links to tools better for editing XSLT
7/16/2000 - Added ability to save XML and XSL separately, file dialog box
7/16/2000 - Added support for Instant Saxon
7/16/2000 - Added simple command to launch browser
7/16/2000 - Fixed bug that would cause program to abort when invalid XML encountered
7/16/2000 - Fixed bug where XSL processing errors would cause program to enter endless loop
7/13/2000 - First released to web