Brought to you by: Check It Out! Java XML Programmers Reference Download Source Code Read part 1 Read part 2 Read part 4 Submit a question on Java XML Read our list of questions and answers on Java XML

• Smaller memory footprint — translet and runtime classes are minimized by including only those XSLTC features required for that particular transformation
• Performance — Sun claims performance gains between 30-270% over Saxon, Xalan, and XT processors, depending upon stylesheet and XML input sizes — performance is even more of a key issue on limited devices
• Freedom — runtime and translet classes are Java 1.1 bytecode
• Reduced network traffic — XSL stylesheets need not be downloaded as they are already distributed with an application

Traditional transformation engines have large memory footprints. For example, Apache's Xalan-Java 2.0.1 requires xalan.jar and xerces.jar (the Apache Xerces XML parser). This represents over 2.2 MB of bytecode! Not many would argue that this is an unreasonable demand for most of today's lightweight clients.

• The XSLTC runtime JAR xsltcrt.jar (119 KB, 117 KB reduced)
  
  
• The xml.jar file (126 KB)
  
  
• Any translet class files your application needs to use (typically 2 —10KB each, depending upon the size and complexity of the original XSL stylesheet)

XSL functionality used in most stylesheets is included in xsltcrt.jar, while functionality specific to certain stylesheets (and not already included in xsltcrt.jar) is compiled into those stylesheets' translets. This approach minimizes the size of the runtime library without sacrificing XSLT compatibility.

xml.jar was Sun Project X, the precursor to Apache Crimson. It contains the SAX 1.0 and DOM Level 1 interfaces, as well as SAX and DOM implementations. It's important to note that since this JAR file is required at runtime, you are given SAX and DOM parsers for free; there's no need to include another parser such as NanoXML.

Since translets require Sun Project X (xml.jar), which contains both SAX 1.0 and DOM Level 1 parsers, there's no need to include another parser in your lightweight client. The parsers in xml.jar can be used independently and separately from translets, if needed.

The following performance graph was generated from data gathered by XSLTMark (http://www.datapower.com/XSLTMark/).

Kilobytes per second are the total number of bytes in the input and output XML documents divided by twice the elapsed time. See http://www.xml.com/pub/a/2001/03/28/xsltmark/results.html for more information. Although we have compared two different sets of data in the same graph (something the XSLTMark authors warn against), we have still used the graph for general comparisons. With an older version of XSLTC, we see it is second only to XT. Newer versions of XSLTC claim even better performance gains. Since the release notes for release Alpha 5 specifically state, "performance has been greatly improved" over Alpha 4, we'll have to perform more benchmarks to get the clearest performance picture.

Since translets can be distributed with an application, XSL stylesheets no longer need to be downloaded from a server. This is good news for devices using constrained wireless networks, such as the 9.6 kpbs Cellular Digital Packet Data (CDPD) connection. The flexibility of downloading new stylesheets as needed is not always lost, however. Translets, if used in applets, can be downloaded from the server on which the applet was downloaded just like any other Java class.