Define the variability
A variable content container may allow a closed set of alternatives, an extensible family of known elements or arbitrary foreign content. These are different contracts and should not all be implemented with an unconstrained wildcard.
Closed alternatives
Use xs:choice when the permitted child elements are known and governed together. Cardinality on the choice and its members determines whether one or several alternatives can appear. Tests should cover every branch and repeated combinations.
Extensible element families
Substitution groups allow global member elements to stand in for a declared head. This preserves element declarations and validation while letting separately maintained schemas add members, subject to namespace and import relationships.
Foreign content
A wildcard can accept elements from selected namespaces. namespace and notNamespace constraints describe the boundary, while processContents describes the validation expectation. Keep foreign extension content separate from core values when consumers need clear handling rules.
Application behavior
Schema validity does not guarantee that an application can interpret every allowed child. Document dispatch, preservation and fallback behavior. A container is interoperable only when producers know what they may add and consumers know what they must do.
Implementation notes
List the actual categories of children before selecting an XSD mechanism. A finite, jointly governed set belongs in xs:choice. An open family of declared global elements can use a substitution group. Content owned by independent vocabularies may require a namespace-constrained wildcard. Mixing these cases into one unrestricted container makes both validation and application dispatch ambiguous.
Specify cardinality at the level that matches the business rule. Repeating a choice allows multiple alternatives in sequence, while cardinality on a member has a different effect. Build valid examples for every allowed combination and minimal invalid examples for duplicate, missing and out-of-order content. Generated documentation alone often obscures the effective particle model.
Failure modes
Unique Particle Attribution constraints can make apparently reasonable combinations of explicit elements and wildcards ambiguous. Test the schema with the same XSD version and processors used in production. A workaround that validates in one implementation may rely on a 1.1 feature or a processor extension unavailable to partners.
Applications frequently cast children based only on local names. That fails when an extension vocabulary reuses a name or a substitution member arrives from another namespace. Dispatch by expanded name or governing declaration, and define a safe path for allowed content the current application does not understand.
Review checklist
- Variability category identified
- Cardinality examples tested
- Namespaces used in dispatch
- UPA checked across processors
- Unknown children handled safely
- Generated bindings inspected
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 define the variability?
- What executable example or test demonstrates the intended behavior for closed alternatives?
- What executable example or test demonstrates the intended behavior for extensible element families?
- What executable example or test demonstrates the intended behavior for foreign content?
- What executable example or test demonstrates the intended behavior for application behavior?
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
Extensible content models · Analyze an XSD
Frequently asked questions
01What does the Variable Content Containers in XSD reference cover?
Model XML containers whose permitted child content varies by context using choices, substitution groups, wildcards and explicit profiles.
02When should I use this Technical reference guidance?
Use it when designing, reviewing or updating a system that depends on Variable Content Containers in XSD. Apply the guidance to a concrete example and record any project-specific policy that goes beyond the standard.
03How can I verify a Variable Content Containers in XSD design decision?
Create a minimal positive example, a negative or boundary example, and run both through the same processors and consumer versions used in production. Keep the expected outcome with the fixture so the decision remains reproducible.
04What are the limitations of this Technical reference reference?
The page explains a focused technical decision; it does not replace the complete specification, processor documentation or integration testing. Version-specific behavior and external dependencies must still be verified in the target environment.