The compound-document problem
A document may embed elements from several namespaces, such as a host vocabulary containing XHTML, MathML or a domain-specific extension. One schema language and one monolithic grammar are not always the clearest way to validate every part.
Dispatch by namespace
NVDL describes which validation action applies to sections associated with a namespace. A section can be validated with an XSD, RELAX NG schema or another supported validator, allowed without validation, rejected or attached to a processing mode.
Modes and context
Modes let dispatch behavior change according to the surrounding validation flow. They support cases where the same namespace requires different handling in different host contexts. Keep mode transitions small and documented because hidden dispatch logic is difficult to troubleshoot.
Validation reports
A useful compound-document report identifies both the selected section and the validator that failed. Without that context, a user may receive an XSD or RELAX NG error without knowing why that schema was applied to the element.
Security and schema resolution
Dispatch can activate several schema processors and resource resolvers. Control the allowed validators, local schema catalog and network access. A namespace URI should not automatically trigger arbitrary remote schema retrieval.
Implementation notes
Inventory every namespace that can occur in the compound document and assign an explicit action: validate with a named schema, allow, reject or attach further processing. A default rule should reflect a conscious trust policy. Silently allowing every unknown namespace defeats the purpose of dispatch, while rejecting all unknown content can block legitimate extension vocabularies.
Keep dispatch modes small and name them for the document context they represent. Resolve grammar resources through a local catalog and pin their versions alongside the NVDL script. A validation report should include the namespace section, selected mode, validator and underlying message so an author can identify both the failing content and why that validator handled it.
Failure modes
Namespace sections are determined by the compound structure, not by visual prefix changes. Tests that vary prefixes while preserving namespace URIs catch implementations or surrounding scripts that accidentally compare lexical names. Embedded no-namespace content also needs an explicit policy rather than falling through rules written only for named vocabularies.
Dispatch can invoke several processors with different resource and security behavior. One validator may resolve external entities or fetch imports even when another is locked down. Apply network, file and expansion limits consistently to every processor and test the complete pipeline with malicious as well as invalid documents.
Review checklist
- All namespaces classified
- Default action intentional
- Modes documented
- Schemas catalog-resolved
- Reports retain dispatch context
- Every validator sandboxed
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 the compound-document problem?
- What executable example or test demonstrates the intended behavior for dispatch by namespace?
- What executable example or test demonstrates the intended behavior for modes and context?
- What executable example or test demonstrates the intended behavior for validation reports?
- What executable example or test demonstrates the intended behavior for security and schema resolution?
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
Namespace strategies · Rule-based validation
Frequently asked questions
01What does the NVDL for Compound XML Documents reference cover?
Use Namespace-based Validation Dispatching Language concepts to route parts of compound XML documents to the appropriate schemas.
02When should I use this Technical reference guidance?
Use it when designing, reviewing or updating a system that depends on NVDL for Compound XML Documents. Apply the guidance to a concrete example and record any project-specific policy that goes beyond the standard.
03How can I verify a NVDL for Compound XML Documents 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.