Schematron Phases: Context-Specific XML Validation
Schematron phases are a powerful structural mechanism in ISO Schematron that allow developers to group validation patterns and apply them conditionally based on workflow stages, user roles, or runtime environments. By enabling selective execution of validation rules rather than enforcing a monolithic schema, phases transform XML quality assurance into a dynamic, context-aware process. This article explains how Schematron phases work, how they are configured, and how they facilitate context-specific XML validation across different document lifecycles.
What Is a Schematron Phase?
In Schematron, rules and assertions are organized into
<pattern> elements. By default, a Schematron
validator evaluates all active patterns defined within a schema. A
Schematron <phase> element overrides this behavior by
grouping a specific subset of patterns together under a unique
identifier.
A phase does not define new business logic; instead, it acts as a
selective filter. It references existing patterns using
<active> elements, instructing the Schematron
processing engine to evaluate only the specified patterns when that
particular phase is invoked.
How Phases Work: Structure and Syntax
Phases are declared at the top of a Schematron document, directly
inside the root <schema> element before the pattern
definitions.
<schema xmlns="http://purl.oclc.org/dsdl/schematron" defaultPhase="draft">
<phase id="draft">
<active pattern="structural-rules"/>
</phase>
<phase id="final">
<active pattern="structural-rules"/>
<active pattern="metadata-rules"/>
<active pattern="quality-assurance-rules"/>
</phase>
<pattern id="structural-rules">
<!-- Core structure checks -->
</pattern>
<pattern id="metadata-rules">
<!-- Metadata completeness checks -->
</pattern>
<pattern id="quality-assurance-rules">
<!-- Strict QA and publishing checks -->
</pattern>
</schema>In this setup: * The defaultPhase attribute on the
<schema> element specifies which phase runs if no
phase parameter is passed to the processor. * The special keyword
#ALL can be passed to execute every pattern in the document
regardless of phases.
Enabling Context-Specific Validation
Schematron phases enable targeted validation by decoupling the full rule set from specific execution contexts. Common use cases include:
1. Workflow Stage Validation
XML documents typically evolve through distinct phases such as drafting, editing, and publishing. Enforcing strict final validation rules during the early draft stage creates friction for content creators. Phases allow progressive validation: * Authoring Phase: Validates basic XML structure and required elements so authors can save incomplete drafts. * Editorial Phase: Checks style guides, terminology, and cross-references. * Archival/Publishing Phase: Enforces strict compliance, verifying checksums, unique IDs, and external link integrity.
2. Role-Based Validation
Different stakeholders in an organization are responsible for different parts of an XML document. An author may only need to validate content elements, while a data engineer must validate database-bound metadata. Phases allow systems to run role-specific checks for each user class without maintaining separate schema files.
3. Partner and Distribution Profiles
When exchanging XML documents with multiple external vendors or aggregators, each recipient may require a specific dialect or subset of constraints. Phases permit maintaining a single canonical Schematron file while exposing distinct validation profiles tailored to each partner’s technical requirements.
Invoking Phases During Processing
To apply context-specific rules, the invoking application or command-line tool passes the phase name as a parameter to the XSLT or Schematron processor:
- In command-line processors (such as Saxon or SchXslt), you provide
the parameter directly:
phase=final. - In automated continuous integration (CI/CD) pipelines, build scripts can trigger the appropriate phase depending on whether the build targets a staging, QA, or production deployment.
Benefits of Schematron Phases
- Single Source of Truth: Centralizes all document rules into a single schema file while supporting multiple validation scenarios.
- Improved Performance: Reduces processing overhead by running only the rules necessary for a given context.
- Better User Experience: Prevents irrelevant errors from blocking users at intermediate stages of the content lifecycle.