XSD Design Pattern Analyzer
Inspect declaration scope, reuse and namespace signals to identify the dominant XML Schema design pattern.
Analyze the schema to see its declaration profile.
How XSD design patterns differ
| Pattern | Global declarations | Typical trade-off |
|---|---|---|
| Russian Doll | Root element; anonymous local structure | Encapsulation, limited reuse |
| Salami Slice | Many reusable elements | Element reuse, wider coupling |
| Venetian Blind | Named types; few root elements | Type reuse with controlled roots |
| Garden of Eden | Elements and named types | Maximum reuse, larger public surface |
How to read a pattern result
The reported pattern is a description of visible declaration scope, not a quality score. A vocabulary can deliberately combine a small set of global document elements, reusable named types and local implementation details. That mixed result may be easier to evolve than forcing every component into one textbook category. Review the list of global elements and types as the public surface that other schema documents, XPath expressions and generated bindings can depend on.
A surprising count is often the useful finding. Too many global elements can expose internal vocabulary names and increase coupling; too many anonymous local structures can duplicate rules or prevent intentional reuse. Check whether each global component represents stable identity, reusable structure or an extension contract. Components made global only for speculative reuse should be challenged during design review.
Verify the complete schema set
The browser analyzes one pasted schema and does not resolve xs:include, xs:import, xs:redefine or xs:override. A production conclusion therefore requires loading the complete schema set with the same catalog and processor configuration used by consumers. Run valid and invalid instances, inspect namespace qualification, and test generated bindings before changing declaration scope.
The analyzer complements the detailed global vs. local XML Schema design guide. It does not perform XSD conformance validation or resolve imported schema sets.
Frequently asked questions
01What are the four common XSD design patterns?
Russian Doll uses local elements and anonymous types; Salami Slice emphasizes reusable global elements; Venetian Blind combines global named types with a limited number of global roots; Garden of Eden makes both elements and types broadly global.
02How does the analyzer detect an XSD pattern?
It counts top-level elements, top-level named complex and simple types, local element declarations, anonymous types and references. It then applies documented heuristics to the declaration mix.
03Is the detected pattern a formal XSD property?
No. Pattern names describe design conventions, not normative XML Schema categories. Large schema sets can mix patterns, so the result is a structural signal rather than a conformance verdict.
04Does a Venetian Blind schema require named types?
Yes. The central characteristic is reusable global type definitions while most element declarations remain local, apart from one or more global document roots.
05Why can too many global elements increase coupling?
A global element can be referenced from many contexts and participates in a namespace-wide symbol space. That reuse is useful, but changing the declaration may affect more consumers.
06What does elementFormDefault change?
It controls whether locally declared elements must be namespace-qualified in instance documents by default. It does not change whether the declarations themselves are global or local.
07Can one XSD file use more than one pattern?
Yes. Real schemas often use named global types for core concepts, global elements for selected substitution or reuse points, and anonymous local structures for narrow contexts.
08Does the analyzer resolve xs:include or xs:import?
No. The current browser analyzer inspects one pasted schema document and reports include/import declarations, but it does not fetch or merge referenced schemas.
Pattern changes are contract changes
Moving a local declaration to global scope can change more than file organization. Other schemas may begin referencing it, generated code can expose a new top-level type or element, and substitution or identity behavior can become part of the supported vocabulary. Moving a global declaration inward can break those dependencies even when example instance documents still validate. Search schema repositories, XPath expressions, bindings and documentation before changing scope.
Likewise, replacing an anonymous type with a named type creates an addressable reuse point. That can be valuable when two elements intentionally share structure, but it also creates a public name whose future restrictions and extensions affect several consumers. Name types for stable domain meaning rather than their current field list, and avoid a global component merely because two fragments happen to look alike today.
Use the result in a design review
Record the counts, then identify the components responsible for the dominant classification. Review document roots, shared types, element references, groups and wildcard extension points separately. Ask which components represent vocabulary identity, which represent reusable structure and which are private implementation detail. The decision is easier to defend when every global declaration has one of those explicit roles.
Add a dependency check before approval. Compile the full schema set with a controlled catalog, validate retained instances, regenerate bindings in a clean workspace and run consumer tests. Compare the analyzer result before and after the proposed change so the review records how the public surface moved, not just whether the edited XSD remains syntactically legal.