The definitive sources are the W3C XSLT and XPath recommendations: W3C Recommendation XSL Transformations (XSLT) Version 1.0 and XML Path Language (XPath) Version 1.0.

For a brief listing of tutorials, discussion forums, and other materials, see Getting up to speed with XSLT.

Xalan-Java version 2.1.0 has been tested with Xerces-Java version 1.4. See Status.

Use the Xalan-Java 1 compatibility JAR to recompile and run your Xalan-Java 1 applications with Xalan-Java 2. For more information, see Using the Xalan-Java version 1 API.

TrAX is the Transformation API for XML. In November 2000, TrAX was revised and incorporated into JAXP, the JAVA API for XML Processing. JAXP (including TrAX) provides users a standard, vendor-neutral API for working with (and transforming) XML documents. You can use this API to build applications that are not bound to the particular implementation details of a given XML parser or XSL transformer.

Xalan-Java includes the JAXP packages, implements the TrAX portion of that API (javax.xml.transform....), and includes xerces.jar from Xerces-Java, which implements the parser portion of the API (javax.xml.parser....).

For more information, see TRaX (Transformation API for XML) and Java API for XML Processing 1.1 Public Review 2.

Xalan-Java supports two strategies for chaining together a series of transformations such that the output of each transformation provides input for the next transformation.

• For each transformation in the series, you can set one SAX ContentHandler to process the input, and another ContenHandler to process the output.
  
  
• You can also set up a series of parent-child relationships between an XMLReader and one or more XMLFilters.

For the details and links to examples, see Using transformation output as input for another transformation.

The JDK 1.3 automatically places everything in the lib/ext directory in front of everything you place on the classpath. If this directory contains a version of DOM, JAXP, or Xerces that predates the Xalan-Java distribution you are using, you may have problems!

The IBM JDK 1.3 includes an earlier version of xerces.jar in the lib/ext directory, a version that does not implement the JAXP 1.1 interfaces and therefore does not work with the current Xalan release. Accordingly, you must either purge the xerces.jar that is in that directory or overwrite it with the xerces.jar that is included with the Xalan distribution.

The SUN JDK 1.3 includes a pre-1.1 version of the JAXP in crimson.jar. Either purge the crimson.jar in that directory or overwrite it with a newer crimson.jar that includes and implements the JAXP 1.1 interfaces.

This error occurs when Xalan tries to add a Node to a Document node where it isn't allowed. For example, attempting to add non-whitespace text to the DOM Document node produces this error.

The error can also occur when a Document node is created with the DOMImplementation createDocument() method, which takes a qualified name as an argument and creates an element node. If you then pass the returned Document node to Xalan, you get a "DOM006 Hierarchy request error" when Xalan tries to add a second element to the Document node. The solution is to either use the DocumentBuilder newDocument() method to create a Document that does not contain an element node, or use a DocumentFragment. It should be noted that the DocumentBuilder newDocument() method is "Non-preferred" according to the JAXP 1.1 documentation.

In the ongoing development of Xalan-Java, enhancing performance is the primary goal of the Xalan-Java team. Here are some preliminary suggestions for you to keep in mind as you set up your applications:

• Use a Templates object (with a different Transformers for each transformation) to perform multiple transformations with the same set of stylesheet instructions (see Multithreading).
  
  
• Set up your stylesheets to function efficiently.
  
  
• Don't use "//" (descendant axes) patterns near the root of a large document.
  
  
• Use xsl:key elements and the key() function as an efficient way to retrieve node sets.
  
  
• Where possible, use pattern matching rather than xsl:if or xsl:when statements.
  
  
• xsl:for-each is fast because it does not require pattern matching.
  
  
• Keep in mind that xsl:sort prevents incremental processing.
  
  
• When you create variables, <xsl:variable name="fooElem" select="foo"/> is usually faster than >xsl:variable name="fooElem"><xsl:value-of-select="foo"/></xsl:variable>.
  
  
• Be careful using the last() function.
  
  
• The use of index predicates within match patterns can be expensive.
  
  
• Decoding and encoding is expensive.
  
  
• For the ultimate in server-side scalability, perform transform operations on the client. For examples, see appletXMLtoHTML and get-todo-list.

1. xalan.jar and xerces.jar (or the XML parser you are using) must always be on the classpath.
   
   
2. To run the samples in the samples subdirectories, xalansamples.jar must be on the classpath. To run the servlet (in samples/servlet), xalanservlet.jar must be on the classpath along with the javax.servlet and javax.servlet.http packages. Sun distributes the javax.servlet packages in the JSWDK servlet.jar file.
   
   
3. To run extensions (including the samples in samples/extensions), bsf.jar, and bsfengines.jar must be on the classpath. To run extensions implemented in JavaScript, js.jar must also be on the classpath. For information on what you need to run extensions implemented in other scripting languages, see Supported languages.
   
   
4. To run applications that use the Xalan-Java version 1 API, you must put xalanj1compat.jar on the classpath, recompile the application, and be sure xalanj1compat.jar is on the classpath at run time (see Using the Xalan-Java version 1 API).

For more information, see Setting up the system classpath.

Using the EnvironmentCheck utility: To help diagnose classpath problems, try running Xalan's environment checking utility, checked in at xml-xalan/java/src/org/apache/xalan/xslt/EnvironmentCheck.

You can run this utility from the command line as follows:

java org.apache.xalan.xslt.EnvironmentCheck [-out outFile]

You can also call this utility from within your application. For example,

boolean environmentOK = (new EnvironmentCheck()).checkEnvironment (yourPrintWriter);

Be sure to run EnvironmentCheck in the environment where you are experiencing the problem. For example, if you get a NoClassDefFound error from a command-line application, run EnvironmentCheck on the command line with exactly the same classpath. If the error occurs inside your Java application (or in a servlet, etc.), be sure to call the EnvironmentCheck checkEnvironment(...) method from within your running application.

An XSL stylesheet is an XML document, so it can have a DOCTYPE and be subject to validation, right?

The XSLT Recommendation includes a DTD Fragment for XSL Stylesheets with some indications of what you need to do to create a complete DTD for a given stylesheet. Keep in mind that stylesheets can include literal result elements and produce output that is not valid XML.

You can use the xsl:stylesheet doctype defined in xsl-html40s.dtd for stylesheets that generate HTML.

If you are looking for nodes in a namespace, the XPath expression must include a namespace prefix that you have mapped to the namespace with an xmlns declaration. If you have declared a default namespace, it does not have a prefix (see XPath Node Tests). In order to construct XPath expressions to retrieve nodes from this namespace, you must add a namespace declaration that provides a prefix you can include in the XPath expressions.

Suppose, for example, you you want to locate nodes in a default namespace declared as follows:
xmlns="http://my-namespace"

Add a nampespace declaration with a prefix:
xmlns:foo="http://my-namespace"

Then you can use foo: in your XPath expression.

Hint: Don't use default namespaces, and the problem doesn't arise.

For each Xalan download file in xalan-j distribution directory, there is a corresponding signature file. The signature file for xalan-j_2_0_1.tar.gz, for example, is xalan-j_2_0_1.tar.gz.sig.

The .sig files are PGP signatures of the actual .zip or .tar.gz download files. You can use these files to verify the authenticiy of the download. You do not need the .sig file to use the corresponding donwload file.

To check the authenticity of a Xalan distribution, you need a copy of PGP which is available in a number of licenses, including some free non-commercial licenses, either from an mit.edu site or on the pgp.com site. Once you have a version of PGP installed, you should be able to 'verify the signature' of the .sig file, which basically verifies that the corresponding .zip or tar.gz file has not been changed since we signed it.