<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet href="../make-menu.xsl" type="text/xsl"?><html>
   <head>
      <this-is section="using-xsl" page="commandline" subpage=""/>
      <!--
           Generated at 2010-10-29T18:20:48.427+01:00--><title>Saxonica: XSLT and XQuery Processing: Running XSLT from the Command Line</title>
      <meta name="coverage" content="Worldwide"/>
      <meta name="copyright" content="Copyright Saxonica Ltd"/>
      <meta name="title"
            content="Saxonica: XSLT and XQuery Processing: Running XSLT from the Command Line"/>
      <meta name="robots" content="noindex,nofollow"/>
      <link rel="stylesheet" href="../saxondocs.css" type="text/css"/>
   </head>
   <body class="main">
      <h1>Running XSLT from the Command Line</h1>
      <p>A command is available to apply a given stylesheet to a given source XML document. For simple transformations
on the Java platform, use the command:</p>
      <p class="command">java net.sf.saxon.Transform -s:<i>source</i> -xsl:<i>stylesheet</i> -o:<i>output</i>
      </p>
      <p>where <i>source</i>, <i>stylesheet</i>, and <i>output</i> are the source XML file, the XSLT stylesheet,
and the output file respectively.</p>
      <p>For the .NET platform, the command is simply:</p>
      <p class="command">Transform -s:<i>source</i> -xsl:<i>stylesheet</i> -o:<i>output</i>
      </p>
      <p>For a schema-aware transformation, specify the option <code>-sa</code>, or (on the
Java platform only) use the alternate entry point <code>com.saxonica.Transform</code>. 
For more details see <a class="bodylink" href="../schema-processing/satransformcmd.xml">Schema-Aware Transformations</a>.</p>
      <p>For backwards compatibility with previous releases, the prefixes "-s:" and "-xsl:" can be omitted
provided that the source document and the stylesheet are the last two options before any keyword=value
parameters.</p>
      <p>More generally, the arguments consist of a number of options prefixed with "-", then optionally
(for backwards compatibility) the source filename and/or stylesheet filename, then a number of parameters provided as
keyword=value pairs. The options must come first, then the file names if present, then the parameters.</p>
      <p>For this to work, all the necessary Java components must be available on the classpath. See
<a class="bodylink" href="../about/installationjava.xml">Installation</a> for details of how to set up the classpath.</p>
      <p>If you are are not using any additional Java libraries, you can use the simpler form of command (this example
  is for the Home Edition):</p>
      <p class="command">java  -jar <i>dir</i>/saxon9he.jar [options] [params]</p>
      <p><i>Note, however, that this does not work if you need to load user-written extension functions or 
other classes from the classpath. It will therefore not work if your stylesheet uses extension functions
or other plug-in components such as parsers or URI resolvers.</i></p>
      <p>The options are as follows (in any order): </p>
      <table>
         <tr>
            <td content="para">
               <p>-a[:(on|off)]</p>
            </td>
            <td content="para">
               <p>Use the xml-stylesheet processing instruction in the source document
to identify the stylesheet to be used. The stylesheet argument must not be present on the command line.
</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-c:filename</p>
            </td>
            <td content="para">
               <p>Indicates that the a compiled stylesheet is to be loaded from the given filename. 
The stylesheet must have been previously compiled as
described in <a class="bodylink" href="../using-xsl/compiling.xml">Compiling a Stylesheet</a>. If this option is used then the
<code>-xsl:filename</code> option should be omitted.
</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-config:filename</p>
            </td>
            <td content="para">
               <p>Indicates that configuration information should be taken from the supplied
      <a class="bodylink" href="../configuration/configuration-file.xml">configuration file</a>. Any options supplied
      on the command line override options specified in the configuration file.
    </p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-cr:classname</p>
            </td>
            <td content="para">
               <p>Use the specified CollectionURIResolver to process collection URIs passed to the
<code>collection()</code> function.
 The CollectionURIResolver is a user-defined class
that implements the <code>net.sf.saxon.CollectionURIResolver</code> interface.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-dtd:(on|off|recover)</p>
            </td>
            <td content="para">
               <p>Setting <code>-dtd:on</code> requests DTD-based validation of the source file and of any files read using the document()
function. Requires an XML parser that supports validation. The setting <code>-dtd:off</code> (which is the default)
suppresses DTD validation. The setting <code>-dtd:recover</code> performs DTD validation but treats the error as non-fatal if
it fails. Note that any external DTD is likely to be read even if not used for validation, because DTDs can contain
definitions of entities.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-expand:(on|off)</p>
            </td>
            <td content="para">
               <p>Normally, if validation using a DTD or Schema is requested, any fixed or default values defined
in the DTD or schema will be expanded. Specifying -expand:off suppresses this.  (In the case of DTD-defined defaults,
this might not work with all XML parsers. It does work with the Xerces parser (default for Java) and the 
Microsoft parser (default for .NET))</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-explain[:filename]</p>
            </td>
            <td content="para">
               <p>Display an execution plan for the stylesheet. This is a representation of the
expression tree after rewriting by the optimizer. It compbines the XSLT instructions and the
XPath expressions into a single tree. If no file name
is specified the output is sent to the standard error stream. The output is
a tree in XML format.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-ext:(on|off)</p>
            </td>
            <td content="para">
               <p>If <code>ext:off</code> is specified, suppress calls on dynamically-loaded external Java functions. 
This does not affect calls on integrated extension functions, including Saxon and EXSLT extension
functions. This option is useful when loading an untrusted stylesheet, perhaps from a remote
site using an <code>http://</code> URL; it ensures that the stylesheet cannot call arbitrary Java methods
and thereby gain privileged access to resources on your machine.
</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-im:modename</p>
            </td>
            <td content="para">
               <p>Selects the initial mode for the transformation. If this is namespaced, it can be 
written as <code>{uri}localname</code>
            </p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-init:initializer</p>
            </td>
            <td content="para">
               <p>The value is the name of a user-supplied class
that implements the interface <code>net.sf.saxon.Initializer</code>; this initializer will be called during the initialization process,
and may be used to set any options required on the Configuration programmatically. It is particularly useful for such tasks as
registering extension functions, collations, or external object models, especially in Saxon-HE where the option does not exist to
do this via a configuration file. </p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-it:template</p>
            </td>
            <td content="para">
               <p>Selects the initial named template to be executed. If this is namespaced, it can be 
written as <code>{uri}localname</code>. When this option is used, you do not need to supply
a source file, but if you do, you must supply it using the <code>-s</code> option.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-l[:(on|off)]</p>
            </td>
            <td content="para">
               <p>If <code>-l</code> or <code>-l:on</code> is specified, 
causes line and column numbers to be maintained for source documents. These are accessible
using the extension functions <code>saxon:line-number()</code> and <code>saxon:column-number()</code>. Line numbers are useful
when the purpose of the stylesheet is to find errors or anomalies in the source XML file.
Without this option, line numbers are available while source documents are being parsed
and validated, but they are not retained in the tree representation of the document.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-m:classname</p>
            </td>
            <td content="para">
               <p>Use the specified Receiver to process the output from xsl:message. The class must implement
the <code>net.sf.saxon.event.Receiver</code> class. This interface is similar to a SAX ContentHandler,
it takes a stream of events to generate output. In general the content of a message is an XML
fragment. By default the standard XML emitter is used, configured to write to the standard error
stream, and to include no XML declaration. Each message is output as a new document.The sequence of calls to this Receiver is as follows: there is a single <code>open()</code> call at
the start of the transformation, and a single <code>close()</code> call at the end; and each evaluation of an <code>xsl:message</code>
instruction starts with a <code>startDocument()</code> call and ends with <code>endDocument()</code>. The <code>startDocument()</code>
event has a <code>properties</code> argument indicating whether <code>terminate="yes"</code> was specified, and the
<code>locationId</code> on calls such as <code>startElement()</code> and <code>characters()</code> can be used to identify
the location in the stylesheet where the message data originated (this is achieved by passing the supplied <code>locationId</code>
in a call to <code>getPipelineConfiguration().getLocator().getSystemId(locationId)</code>, or to <code>getLineNumber()</code>
on the same object).Select the class <code>net.sf.saxon.event.MessageWarner</code> to have <code>xsl:message</code> output
notified to the JAXP <code>ErrorListener</code>, as described in the JAXP documentation.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-now:yyyy-mm-ddThh:mm:ss+hh:mm</p>
            </td>
            <td content="para">
               <p>Sets the value of <code>current-dateTime()</code> (and <code>implicit-timezone()</code>) for
the transformation. This is designed for testing, to enable repeatable results to be obtained
for comparison with reference results, or to test that stylesheets can handle significant dates and
times such as end-of-year processing.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-o:filename</p>
            </td>
            <td content="para">
               <p>Send output to named file. In the absence of this option, the results go to standard output.
If the source argument identifies a directory, this option is mandatory and must also identify
a directory; on completion it will contain one output file for each file in the source directory.
If the stylesheet writes secondary output files using the <code>xsl:result-document</code>
instruction; this filename acts as the base URI for the <code>href</code> attribute of this instruction.
In the absence of this option, secondary output files are written relative to the current working directory.
The file is created if it does not already exist; any necessary directories will also be created.
If the file does exist, it is overwritten (even if the transformation fails); but not if the transformation
produces no principal result tree.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-opt:0...10</p>
            </td>
            <td content="para">
               <p>Set optimization level. The value is
an integer in the range 0 (no optimization) to 10 (full optimization); currently all values other than 0 result in full
optimization but this is likely to change in future. The default is full optimization; this feature allows optimization
to be suppressed in cases where reducing compile time is important, or where optimization gets in the way of debugging,
or causes extension functions with side-effects to behave unpredictably. (Note however, that even with no optimization,
lazy evaluation may still cause the evaluation order to be not as expected.)
</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-or:classname</p>
            </td>
            <td content="para">
               <p>Use the specified OutputURIResolver to process output URIs appearing in the <code>href</code>
attribute of <code>xsl:result-document</code>.
 The OutputURIResolver is a user-defined class
that implements the <code>net.sf.saxon.OutputURIResolver</code> interface.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-outval:(recover|fatal)</p>
            </td>
            <td content="para">
               <p>Normally, if validation of result documents is requested, a validation error is fatal. Setting
the option <code>-outval:recover</code> causes such validation failures to be treated as warnings. The validation
message is written both to the standard error stream, and (where possible) as a comment in the result
document itself.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-p[:(on|off)]</p>
            </td>
            <td content="para">
               <p>Use the PTreeURIResolver. This option is available in Saxon-PE and Saxon-EE only. It cannot be used in conjunction
with the -r option, and it automatically switches on the -u and -sa options. The effect is twofold. Firstly, Saxon-specific
file extensions are recognized in URIs (including the URI of the source document on the command line). Currently
the only Saxon-specific file extension is <code>.ptree</code>, which indicates that the source document is supplied
in the form of a Saxon PTree. This is a binary representation of an XML document, designed for speed of loading.
Secondly, Saxon-specific query parameters are recognized in a URI. Currently the only query parameter that is
recognized is <code>val</code>. This may take the values <code>strict</code>, <code>lax</code>, or <code>strip</code>.
For example, <code>source.xml?val=strict</code> loads a document with strict schema validation.
</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-r:classname</p>
            </td>
            <td content="para">
               <p>Use the specified URIResolver to process all URIs. The URIResolver is a user-defined class,
that extends the net.sf.saxon.URIResolver class, whose function is to take a URI supplied as
a string, and return a SAX InputSource. It is invoked to process URIs used in the document() function,
in the xsl:include and xsl:import elements, and (if -u is also specified) to process the URIs
of the source file and stylesheet file provided on the command line.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-repeat:integer</p>
            </td>
            <td content="para">
               <p>Performs the transformation N times, where N is the specified integer. This option is useful for
performance measurement, since timings for the first transformation are often dominated by Java warm-up time.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-s:filename</p>
            </td>
            <td content="para">
               <p>Identifies the source file or directory. Mandatory unless the <code>-it</code> option is used.
The source file is parsed to create a tree, and the document node of this tree acts as the initial context
item for the transformation.If the name identifies a directory, all the
files in the directory will be processed individually. In this case the <code>-o</code> option is
mandatory, and must also identify a directory, to contain the corresponding output files.
A directory must be specified as a filename, not as a URL.The source-document can be
specified as "-" to take the source from standard input.<i>For backwards compatibility the source filename can also be specified immediately before the
stylesheet filename, without the <code>-s</code> flag, provided that the <code>-it</code> option
is not present.</i>
            </p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-sa</p>
            </td>
            <td content="para">
               <p>Invoke a schema-aware transformation. Requires Saxon-EE to be installed. This options is not needed if
either (a) another option implying schema-awareness is present (for example <code>-val:strict</code>) or (b)
the stylesheet contains an <code>xsl:import-schema</code> declaration.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-strip:(all|none|ignorable)</p>
            </td>
            <td content="para">
               <p>Specifies what whitespace is to be stripped from source documents (applies both to the principal source
document and to any documents loaded for example using the <code>document()</code> function. The default is
<code>none</code>: no whitespace stripping. Specifying <code>all</code> strips all whitespace text nodes from 
source documents before any further processing,
regardless of any <code>xsl:strip-space</code> declarations in the stylesheet, or any
<code>xml:space</code> attributes in the source document.Specifying <code>ignorable</code> strips all ignorable whitespace text nodes from source documents 
before any further processing,
regardless of any <code>xsl:strip-space</code> declarations in the stylesheet, or any
<code>xml:space</code> attributes in the source document. Whitespace text nodes are ignorable
if they appear in elements defined in the DTD or schema as having element-only content.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-t</p>
            </td>
            <td content="para">
               <p>Display version and timing information to the standard error output. The output also traces
the files that are read and writing, and extension modules that are loaded.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-T[:classname]</p>
            </td>
            <td content="para">
               <p>Display stylesheet tracing information. This traces execution of
each instruction in the stylesheet, so the output can be quite voluminous.
Also switches line numbering on for the source document. If a classname is
specified, it is a user-defined class, which must implement net.sf.saxon.trace.TraceListener.
If the classname is omitted, a system-supplied trace listener is used.For performance profiling, set classname to <code>net.sf.saxon.trace.TimedTraceListener</code>.
This creates
an output file giving timings for each instruction executed. This output file can subsequently
be analyzed to give an execution time profile for the stylesheet. 
See <a class="bodylink" href="../using-xsl/performanceanalysis.xml">Performance Analysis</a>.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-TJ</p>
            </td>
            <td content="para">
               <p>Switches on tracing of the binding of calls to external Java methods.
This is useful when analyzing why Saxon fails to find a Java method to match
an extension function call in the stylesheet, or why it chooses one method over another when several
are available.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-TP:filename</p>
            </td>
            <td content="para">
               <p>This is equivalent to setting <code>-T:net.sf.saxon.trace.TimedTraceListener</code> and <code>-traceout:filename</code>;
that is, it causes trace profile information to be set to the specified file. This output file can subsequently
be analyzed to give an execution time profile for the stylesheet. 
See <a class="bodylink" href="../using-xsl/performanceanalysis.xml">Performance Analysis</a>.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-traceout:filename</p>
            </td>
            <td content="para">
               <p>Indicates that the output of the <code>trace()</code> function should be directed to a specified file.
Alternatively, specify #out to direct the output to System.out, #err to send it to System.err (the default),
or #null to have it discarded. This option is ignored when a trace listener is in use: in that case, trace()
output goes to the registered trace listener.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-tree:(linked|tiny|tinyc)</p>
            </td>
            <td content="para">
               <p>Selects the implementation of the internal tree model. -tree:tiny selects the "tiny tree"
model (the default). -tree:linked selects the linked tree model. -tree:tinyc selects the "condensed tiny tree" model.
See <a class="bodylink" href="../sourcedocs/choosingmodel.xml">
Choosing a tree model</a>.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-u</p>
            </td>
            <td content="para">
               <p>Indicates that the names of the source document and the stylesheet document are URLs;
otherwise they are taken as filenames, unless they start with "http:" or "file:", in which
case they are taken as URLs</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-val[:(strict|lax)]</p>
            </td>
            <td content="para">
               <p>Requests schema-based validation of the source file and of any files read using the document()
or similar functions. Validation is available only with Saxon-EE, and this flag automatically switches on the
-sa option. Specify <code>-val</code> or <code>-val:strict</code> to request strict validation,
or <code>-val:lax</code> for lax validation.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-versmsg:(on|off)</p>
            </td>
            <td content="para">
               <p>If versmsg:off is specified, suppress version warnings. 
This suppresses the warning message that is normally issued
(as required by the W3C specification) when running an XSLT 2.0 processor against a stylesheet
that specifies <code>version="1.0"</code>.
</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-warnings:(silent|recover|fatal)</p>
            </td>
            <td content="para">
               <p>Indicates the policy for handling recoverable errors in the stylesheet: <code>silent</code> means
recover silently, <code>recover</code> means recover after writing a warning message to the system error
output, <code>fatal</code> means signal the error and do not attempt recovery. (Note, this does not
currently apply to all errors that the XSLT recommendation describes as recoverable).
The default is <code>recover</code>.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-x:classname</p>
            </td>
            <td content="para">
               <p>Use specified SAX parser for source file and any files loaded using the document() function.
 The parser must be the fully-qualified class name
of a Java class that implements the org.xml.sax.Parser or org.xml.sax.XMLReader interfaceOne use of this option is to select an HTML parser such as John Cowan's TagSoup rather than
    an XML parser. In this case, the TagSoup JAR file must be on the classpath, and the class
    name to use is <code>org.ccil.cowan.tagsoup.Parser</code>.Another common use is to specify <code>org.apache.xml.resolver.tools.ResolvingXMLReader</code>. This
parser is provided by the Apache commons project, and it customizes the default parser by using
an <code>EntityResolver</code> that resolves external entity references (notable the reference to an
external DTD in a DOCTYPE declaration) by reference to an OASIS catalog file. This can be used to avoid
repeated calls to external web servers (such as the W3C server) for commonly used DTDs such as the XHTML DTD.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xi:(on|off)</p>
            </td>
            <td content="para">
               <p>Apply XInclude processing to all input XML documents (including schema and stylesheet modules as
well as source documents). This currently only works when documents are parsed using the Xerces
parser, which is the default in JDK 1.5 and later.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xmlversion:(1.0|1.1)</p>
            </td>
            <td content="para">
               <p>If <code>-xmlversion:1.1</code> is specified, allows XML 1.1 and XML Namespaces 1.1 constructs. 
This option must be set if source documents 
using XML 1.1 are to be read, or if result documents are to be serialized as XML 1.1. This option
also enables use of XML 1.1 constructs within the stylesheet itself.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xsd:file1;file2;file3...</p>
            </td>
            <td content="para">
               <p>Loads additional schema documents. The declarations in these schema documents are available when
validating source documents (or for use by the <code>validate{}</code> expression). This option may also be used
to supply the locations of schema documents that are imported into the stylesheet, in the case where the <code>xsl:import-schema</code>
declaration gives the target namespace of the schema but not its location.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xsdversion:(1.0|1.1)</p>
            </td>
            <td content="para">
               <p>If <code>-xsdversion:1.1</code> is specified, allows XML Schema 1.1 constructs such as assertions. 
This option must be set if schema documents using XML Schema 1.1 are to be read.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xsiloc:(on|off)</p>
            </td>
            <td content="para">
               <p>If set to "on" (the default) the schema processor attempts to load any schema documents referenced
in <code>xsi:schemaLocation</code> and <code>xsi:noNamespaceSchemaLocation</code> attributes in the instance
document, unless a schema for the specified namespace (or non-namespace) is already available. If set to
"off", these attributes are ignored.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xsl:filename</p>
            </td>
            <td content="para">
               <p>Specifies the file containing the principal stylesheet module. Mandatory unless
the -a option or -c option is used. The value "-"
identifies the standard input stream. If the -u option is specified then the value
must be a URI rather than a filename.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-xsltversion:(2.0|3.0)</p>
            </td>
            <td content="para">
               <p>Determines whether an XSLT 2.0 processor or XSLT 3.0 processor is to be used.
            By default the value is taken from the version attribute of the <code>xsl:stylesheet</code> element</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-y:classname</p>
            </td>
            <td content="para">
               <p>Use specified SAX parser for stylesheet file, including any loaded using xsl:include
or xsl:import. The parser must be the fully-qualified class name
of a Java class that implements the org.xml.sax.Parser or org.xml.sax.XMLReader interface</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>--<i>feature</i>:value</p>
            </td>
            <td content="para">
               <p>Set a feature defined in the <code>Configuration</code> interface. The names of features
are defined in the Javadoc for class <code>net.sf.saxon.FeatureKeys</code>: the value used here
is the part of the name after the last "/", for example <code>--allow-external-functions:off</code>.
Only features accepting a string or boolean may be set; for booleans the values true/false or on/off
are recognized.</p>
            </td>
         </tr>
         <tr>
            <td content="para">
               <p>-?</p>
            </td>
            <td content="para">
               <p>Display command syntax</p>
            </td>
         </tr>
      </table>
      <p>A <i>param</i> takes the form <code>name=value</code>, <i>name</i> being the
name of the parameter, and <i>value</i> the value of the parameter. These parameters are
accessible within the stylesheet as normal variables, using the <code>$name</code> syntax, provided
they are declared using a top-level <code>xsl:param</code> element. If there is no such declaration, the supplied
 parameter value is silently ignored. If the <code>xsl:param</code> element has an <code>as</code>
 attribute indicating the required type, then the string value supplied on the command line is cast
 to this type: this may result in an error, for example if an integer is required and the supplied value
 cannot be converted to an integer.</p>
      <p>A <i>param</i> preceded by a leading question mark (?) is interpreted as an XPath expression.
For example, <code>?time=current-dateTime()</code> sets the value of the stylesheet parameter <code>$time</code>
to the value of the current date and time, as an instance of <code>xs:dateTime</code>, while 
<code>?debug=false()</code> sets the value of the parameter <code>$debug</code> to the boolean value <code>false</code>.
If the parameter has a required type (for example <code>&lt;xsl:param name="p" as="xs:date"/&gt;</code>), then
the supplied value must be compatible with this type according to the standard rules for converting variable
values and function arguments.
The static context for this XPath expression includes only the standard namespaces conventionally bound to the prefixes
<code>xs</code>, <code>fn</code>, <code>xsi</code>, and <code>saxon</code>. The static base URI (used when calling the
<code>doc()</code> function) is the current directory. The dynamic context contains no context item, position, or size,
and no variables.</p>
      <p>A <i>param</i> preceded by a leading exclamation mark (!) is interpreted as an output parameter.
For example, <code>!indent=yes</code> requests indented output. This is equivalent to specifying
the attribute <code>indent="yes"</code> on an <code>xsl:output</code> declaration in the stylesheet.
An output parameter specified on the command line overrides one specified within the stylesheet.
For parameters <code>doctype-system</code>, <code>doctype-public</code>, and <code>saxon:next-in-chain</code>,
a zero-length value is treated as "absent", that is, the effect is to cancel any value that was set within the stylesheet.</p>
      <p>A <i>param</i> preceded by a leading plus sign (+) is interpreted as a filename or directory.
The content of the file is parsed as XML, and the resulting document node is passed to the stylesheet
as the value of the parameter. If the parameter value is a directory, then all the immediately contained
files are parsed as XML, and the resulting sequence of document nodes is passed as the value of the
parameter. For example, <code>+lookup=lookup.xml</code> sets the value of the stylesheet parameter
<code>lookup</code> to the document node at the root of the tree representing the parsed contents
of the file <code>lookup.xml</code>.</p>
      <p>Under most operating systems it is possible to supply a value containing
spaces by enclosing it in double quotes, for example <code>name="John Smith"</code>. This is a feature
of the operating system shell, not something Saxon does, so it may not work the
same way under every operating system or command processor. (In the jEdit console plugin, for example, 
it has to be written as <code>"name=John Smith"</code>)</p>
      <p>If the parameter name is in a non-null namespace, the parameter can be given a value using
the syntax <code>{uri}localname=value</code>. Here <code>uri</code> is the namespace URI of the
parameter's name, and <code>localname</code> is the local part of the name.</p>
      <p>This applies also to output parameters. For example, you can set the indentation level to 4 by
using the parameter <code>!{http://saxon.sf.net/}indent-spaces=4</code>. In this case, however,
lexical QNames using the prefix "saxon" are also recognized, for example <code>!saxon:indent-spaces=4</code>.
See also
<a class="bodylink" href="../extensions/output-extras.xml">Additional serialization parameters</a>.</p>
      <p>If the <code>-a</code> option is used, the name of the stylesheet is
omitted. The source document must contain a <code>&lt;?xml-stylesheet?&gt;</code> processing instruction
before the first element start tag; this processing instruction must have a pseudo-attribute <code>href</code> that
identifies the relative or absolute URL of the stylsheet document, and a pseudo-attribute type whose
value is <code>text/xml</code>, <code>application/xml</code>, or <code>text/xsl</code>. For example:</p>
      <p class="command">&lt;?xml-stylesheet type="text/xsl" href="../style3.xsl" ?&gt;</p>
      <p>It is also possible to refer to a stylesheet embedded within the source document, provided
it has an id attribute and the id attribute is declared in the DTD as being of type ID. For example:</p>
      <div class="codeblock"
           style="border: solid thin; background-color: #B1CCC7; padding: 2px">
         <pre>
            <code>
&lt;?xml-stylesheet type="text/xsl" href="#style1" ?&gt;
&lt;!DOCTYPE BOOKLIST SYSTEM "books.dtd"
  &lt;!ATTLIST xsl:transform id ID #IMPLIED&gt;
&lt;
&lt;BOOKLIST&gt;
  ...
  &lt;xsl:transform id="style1" version="1.0" xmlns:xsl="..."&gt;
  ...
  &lt;/xsl:transform&gt;
&lt;/BOOKLIST&gt;</code>
         </pre>
      </div>
      <table width="100%">
         <tr>
            <td>
               <p align="right"><a class="nav" href="compiling.xml">Next</a></p>
            </td>
         </tr>
      </table>
   </body>
</html>