There are three classes of Saxon processor: “home edition”, “professional edition”, and “enterprise edition”. There are four ways to select the edition you wish to use:

Where edition is one of “he”, “pe”, or “ee”. The actual edition that you get will depend on where the Saxon jar files appear on your classpath. XML Calabash will proceed even if it cannot obtain the requested edition, but dynamic errors will occur if you attempt to use features not available in the edition actually used.

Schema aware processing requires “enterprise edition”; if you request schema aware processing, the processor option is treated as if you'd requested “ee” irrespective of what you actually specified.

The Saxon “professional edition” and “enterprise edition” processors can load an external configuration file to control various aspects of the Saxon processor. There are three ways to specify the location of this file:

The settings in this file take precedence over other, related settings available in Calabash (for example, schema awareness or processor type). This option will cause XML Calabash to throw an error if you are using “home edition”.

There are four ways to enable schema aware processing:

Schema aware processing requires Saxon EE. If schema aware processing is enabled, then PSVIs are passed between steps.

There are four ways to enable debugging:

If debugging is enabled, errors will produce Java stack traces.

There are three ways to enable safe mode:

If safe-mode is enabled, only XProc standard steps can be instantiated and any attempt to access the local filesystem will result in a dynamic error.

An alternate configuration file can be loaded from the command line:

T.B.D.

There are two ways to specify the logging style:

The default logging style for p:log output is “wrapped”. You can specify alternate styles of “plain”, “directory”, or “off” to suppress all p:log output. The value “off” disables all logging, even if individual p:log elements specify an alternate style with cx:logstyle.

There are four ways to specify the entity resolver:

The class specified will be instantiated and used as the entity resolver for all XML documents accessed.

There are four ways to specify the URI resolver:

The class specified will be instantiated and used as the URI resolver for all URIs accessed.

There are four ways to specify extensions:

Valid extension names are “general-values”, “xpointer-on-text”, and “transparent-json”.

There are two ways to specify a namespace binding in the configuration:

These bindings apply (only) to the options, parameters, and step names (if any) specified on the command line. For convenience, the prefix “p” is bound to the XProc namespace by default.

Namespaces in the XML configuration are bound by the normal, XML means.

There are three ways to specify a parameter in the configuration:

All parameters specified will be bound to either the specified parameter input port or the the primary parameter input port if no explicit port is specified.

There are three ways to specify an input binding in the configuration:

The input specified must be an XML document. The string “-” may be used for exactly one input URI to bind that input to stdin.

If the input binding for a particular port is repeated, all of the inputs specified will appear on that port as a sequence of documents.

There are two ways to specify a non-XML input binding in the configuration:

The input specified will be base64 encoded.

T.B.D.

There are three ways to specify an output binding in the configuration:

The result(s) that appear on the named output port will be written to the specified URI. The string “-” may be used for exactly one output URI to bind that output to stdout.

There are two ways to load a library in the configuration:

The steps in the library loaded are only available in --step options. At most one library may be loaded. If no step name is specified, the first step in the library will be used.

There are two ways to load steps in the configuration:

Steps loaded on the command line may come from the optional library. They must have a single primary input and a single primary output. They are treated as if they appeared sequentially in a p:pipeline.

T.B.D.

There are two ways to specify a pipeline in the configuration:

The first non-option command line argument is interpreted as the pipeline URI.

T.B.D.

There are two ways to specify option values in the configuration:

T.B.D.

The step error listener can be specified in the configuration file.

T.B.D.

All of the XML serialization options can be specified with system properties or specified in the configuration file.

The option names supported on both system properties and cc:serialization are: byte-order-mark, doctype-public, doctype-system, encoding, escape-uri-attributes, include-content-type, indent, media-type, normalization-form, omit-xml-declaration, standalone, undeclare-prefixes, and version. In addition, the cdata-section-elements option is supported on cc:serialization. (It's only supported in the configuration file because the values are QNames.)

T.B.D.

Extension functions are specified in the configuration file.

T.B.D.

The FO Processor is specified in the configuration file.

T.B.D.

The CSS processor is specified in the configuration file.

T.B.D.

The XProcConfigurer is specified in the configuration file.

T.B.D.

Default system properties can be specified in the configuration file.

T.B.D.

The HTML parser is specified in the configuration file.

The parser must be “validator.nu” or “tagsoup”.

T.B.D.

Saxon configuration properties (Features) can be specified in the configuration file.

Where “key” is a Saxon FeatureKey and “type” is “integer”, “boolean”, or “string”.

Setting Saxon features through this interface may have unanticipated consequences, use with care.

T.B.D.

There are two ways to specify the SMTP configuration for sending mail.

If you specify a username, you must specify a password, otherwise all the properties are optional. Any unspecified properties will be defaulted by JavaMail to whatever defaults JavaMail uses.

T.B.D.