Grammar Schemas and Rule-Based Schemas

Two validation models

A grammar schema describes permitted structure: which elements and attributes may occur, their order, cardinality and datatypes. A rule-based schema evaluates assertions in a document context. The distinction explains why one language can express a content model elegantly while another can compare distant values or require an element only under a business condition.

What grammar validation does well

XSD and RELAX NG provide a compact model for hierarchical structure and reusable datatypes. They can reject unknown elements, enforce sequences and give schema-aware editors a basis for completion. Trying to encode every cross-field business rule into grammar alternatives often creates a combinatorial model that is difficult to explain and evolve.

What Schematron does well

Schematron binds rules to XPath contexts and evaluates assertions or reports. It can state that totals equal line items, identifiers are unique in a scope, or an address is required for one delivery method. The assertion text can explain the violated policy in domain terms instead of exposing only a failed grammar branch.

Validation order

Run well-formedness and grammar validation before rules that assume stable structure and types. Schematron may operate on the original parsed tree or on a schema-validated information set, depending on the pipeline and processor. Document that choice because defaulted values and type annotations can change what XPath expressions observe.

Avoid duplicate claims

Do not maintain the same constraint independently in XSD, Schematron and application code without an ownership rule. Duplicate constraints drift and produce conflicting errors. Place structural invariants in the grammar, contextual policy in Schematron and operational checks at the application boundary, then test how the layers combine.

Diagnostics are part of the contract

A Schematron assertion should name the failed requirement, identify the relevant value and help the user correct it. Stable rule identifiers allow downstream systems to classify results without parsing prose. Severity, language and location conventions should be agreed before reports become an integration surface.

Choosing the minimum stack

A small closed format may need only XSD. A structurally loose vocabulary may rely heavily on Schematron. Many production systems benefit from both, but additional validators add deployment and versioning cost. Select layers from concrete failure cases, publish processor requirements and keep one representative invalid document for every rule.

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 two validation models?
• What executable example or test demonstrates the intended behavior for what grammar validation does well?
• What executable example or test demonstrates the intended behavior for what schematron does well?
• What executable example or test demonstrates the intended behavior for validation order?
• What executable example or test demonstrates the intended behavior for avoid duplicate claims?
• What executable example or test demonstrates the intended behavior for diagnostics are part of the contract?

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 · XML Schema tutorial