Setting up command line Apache Xalan XSLT processor

You need to put the Xalan jars in the System classpath, create or edit the environment variable called CLASSPATH, set it with a value like this

CLASSPATH=C:\Projects\Java\Runtime\lib\xalan.jar;C:\Projects\Java\Runtime\lib\xml-apis.jar;C:\Projects\Java\Runtime\lib\serializer-2.7.0.jar;

Ultimately you need three JARs on the classpath:

• xalan.jar
• xml-apis.jar
• serializer-#.#.#.jar

You cannot take a shortcut and just specify a folder containing these jars, you must give java the full path to them. For a permanent solution put the three jars in the \lib\endorsed directory, then the classpath will always have them.

You should already have a JRE or JDK in the system PATH as well:

set PATH=C:\SDKs\jdk1.6.0_18\bin;%PATH%

With that in place you can transform XML using XSLT on the command line with the Xalan parser like this:

java org.apache.xalan.xslt.Process -out output.out -in input.xml -xsl transform.xslt

Where

output.out is the file to create,

input.xml is the input xml file to transform, and

transform.xslt is the XSLT XML file to transform the input xml file with.

This is handy because you can also give the JVM 2GB of heap memory like this to process large input files:

java -Xms2g -Xmx2g org.apache.xalan.xslt.Process -out output.out -in input.xml -xsl transform.xslt

If you are runnng into out of memory heap space errors parsing XML with XSLT, this is a good way to get past that problem. If you cannot get further beyond your out of memory errors, then look at breaking apart the XML with Java or Perl somehow before transforming it with XSLT. You might even be able to use 64-bit JVM to address a huge amount of memory much larger than you probably have available in the physical machine.

Validating XML against a Schema (XSD)

Notepad++
Notepad++ has an optional plugin to allow you to validate an XML file against an XSD (this is good because it is a free "gratis" tool).

First, download and install Notepad ++ here

Download and add XML tools plugin for Notepad ++ here

Download the ExternalTools.zip as well from the sourceforge link above and extract the contents to the Notepad++ install folder.

Restart Notepad ++

Open XML file to validate, Click Plugins | XML Tools | Validate now

A window will pop up with errors or validation successfully completed message.


jEdit
jEdit also has optional plugin to validate XML against an XSD.

First download jEdit here

Open jEdit and click Plugins | Plugin Manager

Check the box for XML plugin, click install button

Open the XML file, validation errors appear as red underlines.

Also in jEdit you can open Plugins | XML | Parse as XML will open a window and show a tree navigation of the XML jumping to the first error found if any.

cygwin
An optional package to install in cygwin is called libXML2, this package includes a command line tool named xmllint which can also validate XML against an XSD
$ xmllint --schema /cygdrive/c/path/to/xsd/myschema.xsd /cygdrive/c/path/to/xml/myxml.xml

xsltApplyOneTemplate: problem with xsl:with-param

If you happen to be writing XSLT and are getting a strange error such as this:

xsltApplyOneTemplate: problem with xsl:with-param

But the template seems to run and produce the output, then it could be a typo problem with one of your templates. I ran into this and it took some time to actually discover the problem, (there was a lot of XSLT templates to look at):

I had created a template like this:
<xsl:template match="*[contains(@class,' map/topicref ')]" name="topicrefNestedSection" mode="nestedSection">
<xsl:with-param name="level" />

It should be changed to this:
<xsl:template match="*[contains(@class,' map/topicref ')]" name="topicrefNestedSection" mode="nestedSection">
<xsl:param name="level" />

For some reason I put an xsl:with-param instead of an xsl:param tag. This typo is, for some reason, NOT an XSLT syntax error that is caught by the processor. The only indication I found of a problem is the messages printed by the XSLT processor. Obviously the parameter passed to the template was not working when I was using xsl:with-param and began working once I fixed the typo.

XSLT brings back memories

Komodo is what I have been using for XSLT debugging for a OAISIS DITA open toolkit project I am currently on. I have been taking some specialized DITA sample data and adapting the DITA open toolkit dita2docbook transform to the client specifications. In ActiveState Komodo, I love being able to set break points in the XML input or the XSLT and step through the execution. It is very handy to see the order of execution or what template is used for a particular part of a large XML collection. However it is very annoying that I cannot see a partial output of the transform... also the watch options in Komodo do not seem to work (I get exceptions). I have used Oxygen XML at a previous job and liked it but can't remember if it was any better than Komodo in these areas. I may have to go on a hunt for a new XSLT IDE that allows me to:

• set break points in xml source or xslt and execute a transform in debug (stepping mode)
  
• inspect using xpath while in debug (stepping mode)
• view partial xslt transform output in debug mode
• select which xslt processor (Saxon, Xalan, MSXSL or Xerces)
• perform XSL-FO transforms with Apache FOP

I have also used Eclipse as a XSLT development tool, I even had setup a process such that changes made to sample input XML, or the project XSLT files would trigger a transform using Apache Ant and then a second transform using Apache FOP and finally launch a PDF viewer to check the results. I will try to find time to post those Ant scripts and how I configured the Eclipse project to do it.

Programming in XSLT reminds me of when I was an intern working for Tracy, ah the memories, back then I used UltraEdit and just did command line XSLT processing with MSXSL. I was finishing my CS degree writing a compiler and had the crazy idea that I could generate XML with the tokenizer and parser and use XSLT to actually transform it into assembly. I was too worried about the project deadline to actually try it. I almost did it in Perl but chickened out and just used C++ with Visual Studio. I hadn't taken much Java and, at the time, Java seemed like too much typing. C# had just come out and I didn't dare try to learn a new language while also learning how to write a compiler.