XSD guide
XSD targetNamespace and elementFormDefault
Predict which instance elements must be namespace-qualified, separate schema vocabulary from target vocabulary, and fix no-declaration validation failures.
9 min read · Updated 2026-08-21
The short answer
targetNamespace assigns the schema's global declarations to a vocabulary namespace. elementFormDefault controls whether locally declared instance elements use that namespace by default: qualified puts them in the target namespace, while unqualified leaves them in no namespace unless an individual declaration overrides the form. Neither setting is created by the xs prefix used to write the schema.Keep schema language and target vocabulary separate
The xs prefix names XML Schema's own elements such as schema and complexType. targetNamespace names the application vocabulary being declared. A separate prefix such as tns is conventionally bound to that target URI for references between schema components.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:example:orders"
xmlns:tns="urn:example:orders"
elementFormDefault="qualified">
<xs:element name="order">
<xs:complexType><xs:sequence>
<xs:element name="id" type="xs:string"/>
</xs:sequence></xs:complexType>
</xs:element>
</xs:schema><order xmlns="urn:example:orders"><id>42</id></order>Apply form rules only to local declarations
Global element declarations belong to the target namespace when one exists. elementFormDefault affects local element declarations nested inside type definitions or model groups; qualified makes their instance names use the target namespace, while the default unqualified form leaves them outside it.
- Check whether the failing declaration is global or local.
- Inspect form on the local declaration before the schema-wide default.
- Compare namespace URI plus local name in the instance.
- Treat attributeFormDefault as a separate decision for local attributes.
Debug from the root declaration inward
A no-matching-global-declaration error at the root usually means the instance root is in the wrong namespace or the wrong schema set was loaded. Once the root matches, an unexpected local child often reveals an elementFormDefault mismatch.
Validate one minimal instance containing the root and a single local child. Then add the remaining content back in schema order so namespace errors are not mixed with occurrence or sequence failures.
Prove the fix
- Validate a minimal pairProve the root and one local child before restoring the full instance.
- Read the root errorIdentify wrong namespace and missing schema-set causes at the document root.
- Review namespace identityCompare expanded names instead of source prefixes while debugging.
Related guides
- How to validate XML against an XSDSeparate parsing from schema validation, load the complete schema set, and reduce validation errors to the smallest failing instance.
- How to fix “Element is not expected” in XSDUse the expected-element list to find namespace, order, or occurrence mistakes instead of deleting the child the validator names.
- Why the default XML namespace does not apply to attributesDistinguish unprefixed element and attribute names, qualify attributes deliberately, and prevent namespace-aware lookups from returning nothing.
Get started
Bring order to the XML your team can't afford to ignore.
Create a free account and get a private workspace to search, validate, diff, and monitor your XML feeds, sitemaps, schemas, and vendor integrations.