Chapter 3Implicit validation

Important

This is an experimental feature. The design may change in subsequent releases.

The XProc validation steps (p:validate-with-nvdl, p:validate-with-relax-ng, p:validate-with-schematron, p:validate-with-xml-schema, p:validate-with-json-schema, and validate-with-dtd) provide flexible, robust options for validation. But in the XPath data model, XML Schema validation has a special significance because it can effect the types of elements and attributes in XML documents.

If you are using Saxon EE, you can enable implicit validation of inputs. This is not as flexible as using the p:validate-with-xml-schema step, but it offers a level of convenience.

Note

This is an implementation-defined extension. Pipelines that rely on implicit validation may not run, or may produce unexpected results, when another XProc processor is used.

When implicit validation is enabled, it applies to one or more steps. When implicit validation is in force for a step, all the XML documents that appear on the step’s primary input port will be XML Schema validated. The step will throw an exception if validation fails.

Implicit validation doesn’t apply to non-primary input ports. If validation applied to all ports, then you’d have to have an XML Schema for XSLT stylesheets to use the p:xslt step, and a schema for any document fragments that you were inserting with p:insert, etc.

You can validate non-primary inputs with an explicit validation step or by passing them through the primary input port of some other step, such as p:identity.

There’s only one, global context for schemas and catalogs. You can’t load different schemas for the same namespace in different steps, nor can you have a catalog that applies to only some steps.

From the configuration file

Setting the cc:validation-mode in the configuration file applies implicit validation to all steps. The validation mode can be either strict or lax.

If cc:try-namespaces is true, implicit validation will attempt to locate a schema using the namespace URI. (If a schema is not already loaded.)

If cc:use-location-hints is true, implicit validation will attempt to locate a schema using schema location hints in the source document. (If a schema is not already loaded.)

Additional schema documents can be loaded directly from the configuration file with cc:xml-schema elements.

Additional catalogs, consulted when trying the namespace URI to locate a schema, can be added directly from the configuration file with cc:catalog elements.

From the command line

Options specified on the command line take precedence over any values specified in the configuration file.

Using the --validation-mode option applies implicit validation to all steps. The validation mode can be either strict or lax.

If --try-namespaces is specified, implicit validation will attempt to locate a schema using the namespace URI. (If a schema is not already loaded.)

If --use-location-hints is specified, implicit validation will attempt to locate a schema using schema location hints in the source document. (If a schema is not already loaded.)

Additional schema documents can be loaded from the command line with the --xml-schema option.

Additional catalogs, consulted when trying the namespace URI to locate a schema, can be loaded from the command line with the --catalog option.

From a pipeline

Putting the cx:validation-mode attribute on a step enables implicit validation for that step. Specified on p:declare-step, it applies to all instances of that step type.

A pipeline can include cx:use-catalog and cx:import-schema directives in a p:pipeinfo to load additional catalogs or schemas.

All of the catalogs and schemas declared in any step type that could be called are loaded before execution begins.