Schematron Processing and Report Flow

Inputs to validation

A Schematron run combines an instance document, a Schematron schema, a selected phase and processor configuration. Includes, namespace bindings and parameters are also inputs even when a command hides them. Record those values so a report can be reproduced rather than attributed vaguely to “the schema.”

Pattern activation

The selected phase determines which patterns participate. If no explicit phase is selected, processor and schema defaults govern behavior. Production systems should choose a phase deliberately and include it in the report metadata. A successful run against the wrong phase is a configuration failure, not evidence of document quality.

Context matching

Active rules match context nodes using XPath. Namespace prefixes in the Schematron schema must be bound to the namespace URIs used by the document; visible prefix spelling in the instance is irrelevant. Empty context selections are a common source of false success, so tests must prove that representative nodes are actually reached.

Assertion evaluation

For every matched context, assertion and report tests are evaluated. A result should retain rule identity, message, source location and relevant values. Dynamic text can help users understand the failure, but untrusted document values must be escaped in any HTML presentation of the report.

Structured validation reports

SVRL is a common XML representation of fired rules and successful or failed assertions. Applications can transform it into console, HTML or API responses while retaining stable identifiers. Do not reduce the only stored result to formatted prose if later systems need severity, location or policy-level analytics.

Severity and application policy

Schematron can carry roles, flags or other metadata, but the application must define whether a result blocks processing, creates a warning or records information. Keep validation truth separate from workflow decisions: the same policy finding may block publication but merely warn during authoring.

Observability and regression tests

Log processor and schema versions, phase, duration and result counts without storing sensitive document content unnecessarily. Regression fixtures should cover every assertion and report in both firing and non-firing states. When a rule changes, compare the structured reports across the corpus before releasing it to a blocking pipeline.

Questions for a design review

Use this reference to make a review decision, not merely to recognize terminology. Record the concrete document, schema, processor or consumer being discussed; the language and processor versions; and the behavior that must remain compatible. A useful review produces fixtures and an owner for every unresolved assumption.

• What executable example or test demonstrates the intended behavior for inputs to validation?
• What executable example or test demonstrates the intended behavior for pattern activation?
• What executable example or test demonstrates the intended behavior for context matching?
• What executable example or test demonstrates the intended behavior for assertion evaluation?
• What executable example or test demonstrates the intended behavior for structured validation reports?
• What executable example or test demonstrates the intended behavior for severity and application policy?

Include at least one ordinary case, one boundary case and one deliberately invalid or unsupported case. Check the result in the actual production toolchain, because parsers, validators, code generators and reasoners do not all implement the same optional features. Store the selected contract version with the test result, then repeat the review when a dependency, namespace, profile or public declaration changes.

Continue with a working reference

Patterns, phases and diagnostics · XML validation pipelines