Read our list of questions and answers on Java XML
XSLT Compiler (XSLTC)
The XSLT Compiler, originally produced by Sun Microsystems, but now donated to the Apache XML Project, is a tool for compiling extensible stylesheets into lightweight Java code. The compiled XSL sheets consist of standard Java bytecode and are called translets. During runtime, whenever your code wants to transform some XML, only three steps need be taken:
Ask the XSLTC runtime to parse an XML document
Pass the object representing the parsed XML to the translet, along with an object implementing interface org.xml.sax.DocumentHandler or org.apache.xalan.xsltc.DOM
Tell the translet to transform() the parsed XML
The translet calls back into the object implementing the org.xml.sax.DocumentHandler interface using the standard SAX 1.0 callback mechanism, or builds a DOM-style tree with the object implementing org.apache.xalan.xsltc.DOM.
In this way, the XSLTC runtime and translets can be used to repeatedly generate any type of output based upon original stylesheets and any input XML.
Compiled stylesheets are called translets.
The XSLT Compiler is itself written in Java, so translet creation can be done on any operating system with a Java 2 VM. Translets are merely Java classes, but are designed to run on any Java VM, not just Java 2 VMs. Since they are class files, their compilation is usually done with build scripts along with the rest of your project code.
The Constructor of Useful Parsers (CUP) Parser Generator
The Byte Code Engineering Library (BCEL)
The CUP Parser Generator is used to generate a Java parser and scanner from a stylesheet (the grammar). BCEL is used by XSLTC to convert the parser and scanner from Java source code to bytecode. Both are included as JARs in the Xalan distribution.
In this section, we will:
Examine what is supported and not supported by XSLTC
Discuss the benefits of translets over traditional transformation engines, specifically in regard to lightweight clients
Make a translet using a real example
Review the major classes and steps involved in using the XSLTC
What's Supported, What's Not Supported
Sun and Apache have done an excellent job covering the XSLT 1.0 recommendation. It will be easier to list the features of XSLT that aren't supported by XSLTC, rather than the ones that are.
Feature
Supported
Notes
SAX 2.0 callbacks (org.xml.sax.ContentHandler) for transformed documents
No
SAX 1.0's org.xml.sax.DocumentHandler is supported
Simplified stylesheets
No
The simplified syntax for stylesheets that consist of only a single template for the root node isn't permitted. The syntax is a literal result element that can represent the whole document. For example:
The ability to match elements by their unique id attribute is unsupported
Match patterns using <xsl:key>
No
The ability to match elements using implicit cross-referencing (keys) is unsupported. For more information, see http://www.w3.org/TR/xslt.html#key
Namespace axis
No
The namespace axis isn't supported. It is defined this way: if the starting node in the axis is an element, the axis selects all the namespace nodes that are in scope for that element; otherwise, the axis selects nothing. For instance: <<namespace::*>>
Document validatation
Yes
DTD validation of XML source
DOM parser included
Yes
If you're using XSLTC on a lightweight client, you can make use of the DOM Level 1 parser independent of XSLTC that comes with xml.jar. No need to include the JAR files for NanoXML or other parsers.
SAX parser included
Yes
A SAX 1.0 parser comes with the xml.jar library. The parser can actually be removed and replaced with another SAX library, but the current documentation on how to do this is non-existent.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
REPORTS
ANALYTICS
Follow 
