Command line and configuration changes

The code for the net.sf.saxon.Transform and net.sf.saxon.Query command line interfaces has been refactored. Impact: (a) some legacy options are no longer supported (for example, -ds, -dt, and the ability to separate keyword from value using a space rather than a colon, e.g. "-o output.html"). (b) -opt:? now requests help on that particular option, (c) options that were previously freestanding now accept "on" as a value, e.g. -t can be written -t:on.

A new option -init:initializer is available on all command line interfaces. The value is the name of a user-supplied class that implements the interface net.sf.saxon.lib.Initializer; 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. Saxon only calls the initializer when running from the command line, but of course the same code may be invoked to perform initialization when running user application code.

On the Transform command line interface, the -traceout option now governs the destination of trace output from the standard TraceListener (-T option) as well as from the trace() function. The -TP option (for timing profile information) is extended so a filename can be specified: -TP:filename.

On the Transform command line interface, the option -xsltversion:2.0 or -xsltversion:3.0 indicates whether the XSLT processor should implement the XSLT 2.0 specification or the XSLT 3.0 (also known as 2.1) specification. The default value -xsltversion:0.0 indicates that this decision should be made based on the version attribute of the xsl:stylesheet element. Similar options to set the XSLT processor version are available in the XsltCompiler class (s9api on Java, Saxon.Api on .NET), and via new options in FeatureKeys and in the configuration file.

The com.saxonica.Validate interface accepts some additional options as a result of these changes: -dtd, -ext, -opt, -y. The option -xsdversion was already accepted, but not documented.

The com.saxonica.Validate interface has a new option -stats:filename which produces an output document showing which schema components were used during the validation, and how often. The output is in XML, allowing further processing to produce profiles and coverage reports for the schema. (There are corresponding internal APIs that allow the same effect when validation is invoked from an application, but they are not currently exposed through s9api.)

The command com.saxonica.CompileStylesheet now uses the -key:value argument style throughout. It now accepts a -config:filename argument. The compiled stylesheet output may be specified using -csout:filename

All commands now accept --F:value where F is the name of a string defined in FeatureKeys (the part after "http://saxon.sf.net/feature/"), and value is the string value of the feature; or --F as a synonym for --F:true.

Most places in the code that previously wrote to System.err, or that used System.err as a default destination, now default instead to using Configuration.getStandardErrorOutput(). This can be set to a different destination by calling Configuration.setStandardErrorOutput() (which expects a PrintStream), or by setting the write-only configuration property FeatureKeys.STANDARD_ERROR_OUTPUT_FILE (which expects a filename, which will be appended to). In the configuration file the corresponding setting is global/@standardErrorOutputFile. Note that this only redirects Saxon output; other application output written to System.err is unaffected. Output written directly by command-line interfaces such as net.sf.saxon.Transform is unaffected. Examples of affected output are the default destination of the ErrorListener; the default destination for TraceListener and xsl:message output; the default destination for optimizer tracing and "explain" output.