XProc 3.1: validation steps

The p:validate-with-nvdl step applies [NVDL] validation to the source document.

The source document is validated using the namespace dispatching rules contained in the nvdl document. It is a dynamic error (err:XC0154) if the document supplied on nvdl port is not a valid NVDL document.

The dispatching rules may contain URI references that point to the actual schemas to be used. As long as these schemas are accessible, it is not necessary to pass anything on the schemas port. However, if one or more schemas are provided on the schemas port, then these schemas should be used in validation.

It is a dynamic error (err:XC0053) if the assert-valid option on p:validate-with-nvdl is true and the input document is not valid.

The output from this step is a copy of the input. The output of this step may include PSVI annotations.

Document properties

All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

The p:validate-with-relax-ng step applies [RELAX NG] validation to the source document.

The values of the dtd-attribute-values and dtd-id-idref-warnings options must be booleans.

If the schema document has an XML media type, then it must be interpreted as a RELAX NG Grammar. If the schema document has a text media type, then it must be interpreted as a [RELAX NG Compact Syntax] document for validation. It is a dynamic error (err:XC0153) if the document supplied on schema port cannot be interpreted as an RELAX NG Grammar.

If the dtd-attribute-values option is true, then the attribute value defaulting conventions of [RELAX NG DTD Compatibility] are also applied.

If the dtd-id-idref-warnings option is true, then the validator should treat a schema that is incompatible with the ID/IDREF/IDREFs feature of [RELAX NG DTD Compatibility] as if the document was invalid.

It is a dynamic error (err:XC0155) if the assert-valid option on p:validate-with-relax-ng is true and the input document is not valid.

The output from this step is a copy of the input, possibly augmented by application of the [RELAX NG DTD Compatibility]. The output of this step may include PSVI annotations.

Support for [RELAX NG DTD Compatibility] is implementation-defined.

Document properties

All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

The p:validate-with-schematron step applies [Schematron] processing to the source document.

It is a dynamic error (err:XC0151) if the document supplied on schema port is not a valid Schematron document.

It is a dynamic error (err:XC0054) if the assert-valid option is true and any Schematron assertions fail.

The value of the phase option identifies the Schematron validation phase with which validation begins.

The parameters option provides name/value pairs which correspond to Schematron external variables, to parameters that influence code generation, or to parameters that influence SVRL to XVRL conversion.

There are multiple Schematron implementations. How the Schematron implementation is selected is implementation-defined. A processor might select an implementation based on the schema’s queryBinding attribute and/or provide configuration options. In addition, the special parameter map entry c:implementation (value: QName) may be used to select a Schematron implementation that the processor supports. The list of supported Schematron implementations and their associated values is implementation-defined. If a requested implementation is not available, the processor may throw an error or select another implementation.

The parameters map may contain two special entries, c:compile and c:xvrl, both are maps. If a code-generating implementation such as [Schematron Skeleton] is used, the entries of the c:compile map, for example allow-foreign, will be passed to the code generator. Which parameters the c:compile map supports for a given Schematron implementation is implementation-defined.

If the Schematron implementation produces SVRL by default, the SVRL to XVRL conversion can be influenced by the entries of the c:xvrl map. The same map, with potentially another set of allowed keys and values, can be used to influence XVRL generation from another reporting language. Which parameters this conversion from native reporting format to XVRL supports is implementation-defined.

All other parameters of the parameters option will be passed to the generated code if applicable, or to a hypothetical native Schematron validator that does without code generation.

The result output from this step is a copy of the input.

The output of this step may include PSVI annotations.

Document properties

All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

The p:validate-with-xml-schema step applies [W3C XML Schema: Part 1] validity assessment to the source input.

It is a dynamic error (err:XC0152) if the document supplied on schema port is not a valid XML schema document.

The values of the use-location-hints, try-namespaces, and assert-valid options must be boolean.

The value of the mode option must be an NMTOKEN whose value is either “strict” or “lax”.

Validation is performed against the set of schemas represented by the documents on the schema port. These schemas must be used in preference to any schema locations provided by schema location hints encountered during schema validation, that is, schema locations supplied for xs:import or xsi:schema-location, or determined by schema-processor-defined namespace-based strategies, for the namespaces covered by the documents available on the schemas port.

If xs:include elements occur within the supplied schema documents, they are treated like any other external documents (see [XProc 3.1]). It is implementation-defined if the documents supplied on the schemas port are considered when resolving xs:include elements in the schema documents provided.

The use-location-hints and try-namespaces options allow the pipeline author to control how the schema processor should attempt to locate schema documents necessary but not provided on the schema port. Any schema documents provided on the schema port must be used in preference to schema documents located by other means.

If the use-location-hints option is “true”, the processor should make use of schema location hints to locate schema documents. If the option is “false”, the processor should ignore any such hints.

If the try-namespaces option is “true”, the processor should attempt to dereference the namespace URI to locate schema documents. If the option is “false”, the processor should not dereference namespace URIs.

The mode option allow the pipeline author to control how schema validation begins. The “strict” mode means that the document element must be declared and schema-valid, otherwise it will be treated as invalid. The “lax” mode means that the absence of a declaration for the document element does not itself count as an unsuccessful outcome of validation.

If the step specifies a version, then that version of XML Schema must be used to process the validation. It is a dynamic error (err:XC0011) if the specified schema version is not available. If the step does not specify a version, the implementation may use any version it has available and may use any means to determine what version to use, including, but not limited to, examining the version of the schema(s).

It is a dynamic error (err:XC0156) if the assert-valid option on p:validate-with-xml-schema is true and the input document is not valid. If the assert-valid option is false, it is not an error for the document to be invalid. In this case, if the implementation does not support the PSVI, p:validate-with-xml-schema is essentially just an “identity” step, but if the implementation does support the PSVI, then the resulting document will have additional type information (at least for the subtrees that are valid).

When XML Schema validation assessment is performed, the processor is invoked in the mode specified by the mode option. It is a dynamic error (err:XC0055) if the implementation does not support the specified mode.

The result of the assessment is a document with the Post-Schema-Validation-Infoset (PSVI) ([W3C XML Schema: Part 1]) annotations, if the pipeline implementation supports such annotations. If not, the input document is reproduced with any defaulting of attributes and elements performed as specified by the XML Schema recommendation.

Document properties

All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

The p:validate-with-json-schema step applies a JSON schema validation (as defined in [JSON schema] and other publications) to the source input.

The option default-version can be used to control the schema's version in case it does not specify one itself. If the schema does not specify a version and option default-version is empty, the version used is implementation-defined.

It is a dynamic error (err:XC0163) if the selected version is not supported.

It is a dynamic error (err:XC0164) if the document supplied on schema port is not a valid JSON schema document in the selected version.

It is a dynamic error (err:XC0165) if the assert-valid option on p:validate-with-json-schema is true and the input document is not valid.

The output from this step is a copy of the input.

Document properties

All document properties on the source port are preserved on the result port. No document properties are preserved on the report port.

The p:validate-with-dtd step validates XML with a DTD.

DTD validation differs from the other XML validation technologies in that it is applied during parsing. It isn’t possible to validate an XML data model with a DTD. This step necessarily serializes and reparses.

The p:validate-with-dtd step serializes the document on the source port and parses the serialization with a validating XML parser. The serialization option can be used to control the serialization. If the document to be stored has a “serialization” property, the serialization is controlled by the merger of the two maps where the entries in the “serialization” property take precedence. Serialization is described in [XProc 3.1].

Any warning or error messages produced by the parser will appear on the report port.

It is a dynamic error (err:XC0210) if the assert-valid option on p:validate-with-dtd is true and the input document is not valid.

The output from this step is a copy of the input. If validation was successful, the output may have been augmented by the DTD. (For example, default attributes may have been added.)

Using an internal subset

To validate a document with an internal subset, construct a text document that is a syntactically valid XML serialization with the internal subset, use p:cast-content-type to create an XML document, and then validate the resulting document with this step.

Document properties

If validation fails (and assert-valid is false), all document properties on the source port are preserved on the result port. If validation succeeds, only the base-uri and serialization properties are preserved, the content-type will be application/xml.

No document properties are preserved on the report port.