ODF XSLT Runner is a small Java application that allows you to apply XSLT stylesheets to XML streams included in ODF packages without extracting them from the package. It can be used from the command line. A driver to use it within Ant buildfiles is also available.
ODF XSLT Runner is build by a NetBeans project. After you have checked out the sources from the Mercurial repository, you can open the project in NetBeans and build odfxsltrunner.
A binary release of odfxsltrunner.jar is available in the ODF Toolkit binary package. Please download here. If you need the earlier single jars, please access here.
Building and running odfxsltrunner.jar requires additional jar files. Please see Requirements for details.
Example stylesheets can be found on the ODFXSLTRunner Examples page.
ODF XSLT Runner is called by one of the below command lines:
java -jar odfxsltrunner.jar <style sheet> [-v] [-f <factory>] [-p <path in package>]
[-l log file] <input package> [<output package> [name=value ...]
java -jar odfxsltrunner.jar <style sheet> [-v] [-f <factory>] [-p <path in package>]
[-l log file] -t <input package> <output package> [name=value ...]
java -jar odfxsltrunner.jar <style sheet> [-v] [-f <factory>] [-p <path in package>]
[-l log file] -r <package> [name=value ...]
java -jar odfxsltrunner.jar <style sheet>; [-v] [-f <factory>] [-p <path in package>]
[-l log file] [-x <extract path> ...] -o <input package> <output file> [name=value ...]
java -jar odfxsltrunner.jar <style sheet> [-v] [-f <factory>] [-p <path in package>]
[-l log file] -i <input file> <output package> [name=value ...]
The default is to apply the XSLT stylesheet <style-sheet> to the stream content.xml of the ODF file <input package>. If no <output package> parameter is specified, then the result of the transformation will be printed to the standard output. If an <output package> is specified, the <input package> is copied to the <output package>, and the steam content.xml of the <output package> is replaced with the result of the transformation.
The -p option allows to specify another stream in the package as source of the transformation than content.xml.
The -t options allows to specify a template for the output package. If it is used, the result of the transformation is stored in the content.xml stream (or the stream specified by the -p option) of the <output package>, but other streams of <output package> than that are not modified. This option can be used together with the -i option to create an ODF file from a plain XML file.
The -i option allows to specify a plain XML file <input file> as source of the transformation.
If the -o option is specified, the result of the transformation is stored in the plain <output file> rather than in a ODF package. This is for instance of interest if the result of the transformation is HTML. The -x option can be used to extract further files from the input package. A file or directory specified by this option is extracted from the package into the directory of the output file. The -x option can be specified multiple times.
The -r option allows to modify the content.xml stream (or the stream specified by the -p option) in place. If it is specified, the result of the transformation just replaces the stream that was the source of the transformation. This option should be used with care, because it modifies the original input ODF file.
The -v option enables a verbose mode.
The -f option specifies the ''javax.xml.transform.TransformerFactory'' to use.
Note: When calling ''java'' with the ''-jar'' option, the user class path is ignored. If a transformer factory is used which is not contained in the JRE, like Saxon, odfxsltrunner has to be called without the ''-jar'' option:
java -cp odfxsltrunner.jar:<factory jar> org.odftoolkit.odfxsltrunner.Main ...
The -l option can be used to redirect diagnostic messages into a log file. By default they are printed on standard error.
XSLT Parameters can be passed to the transformation by specifying them as name=value pairs. They must appear behind all other command line parameters.
If the source of a transformation is an ODF package, the XSLT document function can be used to access other files in the package than the one that is the source of the transformation. To do so, the first parameter of the document() function must be a relative URI that references the file that shall be accessed. The reference must be relative to the source file. The second parameter of the document() function must be a node within the source file.
Note: The second parameter specifies the base URI for the resolution of the URI that is specified by the first parameter. This base URI is the base URI of the file that contains the node that is passed as second parameter. If the second parameter is omitted, the base URI is the one of the XSLT stylesheet containing the document() function itself. odfxsltrunner runner uses the rules ODF defines for resolving relative URIs only for URIs that are relative to a file within an ODF package.
Example: When transforming a content.xml file contained in an ODF package, the following rule applies templates to the style elements contained in the style.xml file:
<xsl:apply-templates select="document('styles.xml',.)//office:styles/style:style"/>
ODF XSLT Runner requires Java RE 5, or a later version of Java.
It further requires ODFDOM. This former NetBeans project is pre-configured to build ODFDOM while building ODF XSLT Runner. This requires that the ODFDOM sources are located in a folder odfdom next to the folder of the ODF XSLT Runner project.
Alternatively, the reference to the ODFDOM project in the compile time classpath of the ODF XSLT Runner project may be replaced with a reference to an already compiled odfdom.jar.
At run time, the odfdom.jar file must be either located in folder called lib next to the odfxsltrunner.jar file, or it must be in the classpath.
Note: ODFDOM requires [Apache Xerces] 7. The jar file xercesImpl.jar also must exist in a folder lib next to odfxsltrunner.jar file, or it must be in the classpath. The ODF XSLT Runner NetBeans projects includes a reference to xersesImpl.jar in the runtime classpath which has to be adapted after checking out the project.