How to use a small schema example
Copy an example with its complete xs:schema wrapper, namespaces and version assumptions. Validate at least one matching XML instance and one instance that should fail. The negative fixture is essential: a schema that accepts the intended example may also accept much more than the author realizes.
These examples are starting points for tests, not complete business vocabularies. Give public types and elements domain names, document normalization and extension policy, and run the final schema through every validator and code-binding tool used by consumers.
Reusable named type
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:complexType name="AddressType">
<xs:sequence>
<xs:element name="city" type="xs:string"/>
<xs:element name="postalCode" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:element name="billingAddress" type="AddressType"/>
<xs:element name="shippingAddress" type="AddressType"/>
</xs:schema>A named type separates reusable structure from element identity. The two address elements remain distinct names even though they share fields. This is usually preferable to referencing one global address element when the business roles are observably different.
Local element declarations
<xs:complexType name="OrderType">
<xs:sequence>
<xs:element name="orderId" type="xs:string"/>
<xs:element name="note" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>note is local, optional and tied to OrderType. It should not become global merely because another unrelated type also has a field named “note.” Global identity is a vocabulary promise, not a deduplication technique.
Qualified vocabulary elements
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="https://example.org/order"
xmlns:o="https://example.org/order"
elementFormDefault="qualified">
<xs:element name="order" type="o:OrderType"/>
<xs:complexType name="OrderType">
<xs:sequence><xs:element name="orderId" type="xs:string"/></xs:sequence>
</xs:complexType>
</xs:schema>With qualified local elements, both order and orderId belong to the target namespace. XPath tests must bind a prefix to that URI even when an instance uses it as the default namespace.
Pair every valid example with an invalid fixture
<!-- Invalid: orderId is missing -->
<order xmlns="https://example.org/order">
<note>This should not validate.</note>
</order>A useful test asserts the expected error category rather than an exact processor-specific sentence. Add fixtures for missing required content, unexpected order, repeated values beyond maxOccurs, namespace mistakes and invalid lexical values.
A compatibility change to inspect
<!-- New release: optional client reference -->
<xs:element name="clientReference" type="xs:string" minOccurs="0"/>An optional trailing element can be grammar-compatible for many consumers, but generated bindings, signatures and applications that reject unknown elements may still break. Use the Schema Diff, then run old consumers against new instances before classifying the release.
Turn the examples into a regression corpus
Store each schema beside its valid and invalid XML instances, expected outcome and validation command. Name fixtures for the requirement they exercise rather than numbering them anonymously. When a schema changes, run both the new fixtures and every retained old fixture so a broader content model does not accidentally weaken an unrelated rule.
Use structural assertions for results that can serialize in several equivalent ways. Namespace prefixes and attribute order may change without changing the XML information set. Conversely, a textual diff can miss a changed namespace URI hidden behind the same prefix. Parse results before comparison and include the governing schema release in every report.
A compact, executable corpus is more valuable than a large directory of unclassified samples. Remove fixtures that no longer demonstrate a named requirement, and add a regression case whenever a production defect exposes an assumption the existing examples missed.
Paste the complete schemas into the XSD Pattern Analyzer to inspect declaration scope. Continue with global versus local design for the architectural tradeoffs behind the examples.