XML Schema 1.1 Features and Processor Support

Why XSD 1.1 exists

XML Schema 1.1 adds mechanisms for constraints and extensibility that were difficult to express in XSD 1.0. The language remains based on element and attribute declarations, simple and complex types, particles and namespaces, but it provides more contextual validation power.

Assertions

Assertions attach XPath-based Boolean conditions to complex types. They can express relationships among values, such as a start date preceding an end date. Assertions bring some business rules closer to the type definition, although Schematron may still offer clearer reporting and rule organization.

Conditional type alternatives

Type alternatives allow an element’s governing type to depend on attributes or other testable conditions. This can model polymorphic content without relying only on xsi:type, but it also increases the importance of processor support and test coverage.

Open content and extensibility

Open content mechanisms provide controlled places for elements beyond the explicitly declared model. Extension design must still define allowed namespaces and validation behavior. An open model without a governance policy can accept content that consumers cannot understand.

Deployment reality

XSD 1.0 remains widespread, and not every parser, editor, code generator or platform implements XSD 1.1. Inventory every processor in the toolchain before adopting 1.1-only features. Publish the required XSD version and fail clearly when an incompatible processor is used.

Implementation notes

Start adoption by inventorying every validator, editor, code generator and platform in the delivery chain. Run a small schema using assertions and type alternatives through each one. A successful command-line validation does not prove that generated bindings or partner gateways support the same language version. Publish XSD 1.1 as an explicit processor requirement.

Use assertions for constraints that belong to the type and benefit from schema-level diagnostics. Keep XPath expressions small, namespace-aware and independently tested. If a policy spans several document areas or needs rich reporting, Schematron may remain clearer. The ability to express a rule in an assertion does not establish that it is the best maintenance location.

Failure modes

An assertion evaluated over unexpected optional content can return false, an empty sequence or a dynamic error depending on the expression. Test absent, nilled, repeated and invalidly typed values. Type alternatives can similarly overlap; make tests mutually understandable and document which alternative wins when more than one condition seems applicable.

Fallback to XSD 1.0 is not achieved by silently ignoring 1.1 constructs. Maintain a deliberate 1.0 profile or fail clearly on an incompatible processor. Compare validation corpora across both profiles and label any constraint enforced only in the 1.1 path so consumers know the actual guarantee they receive.

Review checklist

• Processor inventory complete
• Version requirement published
• Assertions unit tested
• Alternative types non-overlapping
• Fallback policy explicit
• Cross-tool corpus validated

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 why xsd 1.1 exists?
• What executable example or test demonstrates the intended behavior for assertions?
• What executable example or test demonstrates the intended behavior for conditional type alternatives?
• What executable example or test demonstrates the intended behavior for open content and extensibility?
• What executable example or test demonstrates the intended behavior for deployment reality?

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

XML Schema tutorial · Schematron assertions