Chapter 3. Implicit validation
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.
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.