Schematron Usage, Phases and Diagnostics

Patterns organize policy

A Schematron schema groups related rules into patterns. A pattern should represent a coherent policy area such as identifiers, financial totals or publication metadata. Small patterns can be activated, tested and reported independently. A single pattern containing every rule hides ownership and makes profiles difficult to assemble.

Rules select context

Each rule applies to nodes selected by its context. Assertions and reports then evaluate XPath relative to those nodes. Choose the narrowest stable context that represents the subject of the requirement. Very broad descendant searches can be slow and can fire the same policy repeatedly in surprising locations.

Assertions and reports

An assertion fails when its test is false; a report fires when its test is true. Assertions fit required conditions, while reports fit the presence of a noteworthy or prohibited situation. Write tests positively when that makes the policy easier to review, and ensure the message agrees with the exact Boolean condition.

Phases create profiles

Phases activate selected patterns for a validation scenario. The same source schema can therefore support a basic intake profile, a stricter publication profile and a migration audit without copying rules. Treat phase identifiers as public configuration and test that every required pattern is active in the intended phase.

Diagnostics and identifiers

Reusable diagnostics can attach detailed information to several assertions. Stable assertion and diagnostic IDs support localization, analytics and automated routing. IDs should identify the policy rather than the wording, because messages can improve without forcing every consuming system to update its classification.

Abstract patterns and reuse

Abstract constructs can reduce repetition when several rules share a shape, but excessive indirection makes the active XPath difficult to inspect. Use parameters for genuine policy families and expand compiled output during debugging. A reviewer should be able to trace a failed assertion back to the source pattern and supplied values.

Implementation checklist

Select the supported Schematron and XPath versions, define phases, compile or execute with a controlled processor and preserve a standard report format. Test empty nodes, namespaces, repeated values and documents that trigger several rules. Measure large inputs and avoid network-dependent includes in production resolution.

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 patterns organize policy?
• What executable example or test demonstrates the intended behavior for rules select context?
• What executable example or test demonstrates the intended behavior for assertions and reports?
• What executable example or test demonstrates the intended behavior for phases create profiles?
• What executable example or test demonstrates the intended behavior for diagnostics and identifiers?
• What executable example or test demonstrates the intended behavior for abstract patterns and reuse?

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

Schematron tutorial · Grammar and rule schemas