cvc-complex-type.2.4.c: strict wildcard, missing declaration

What the message literally means

Xerces matched the wildcard but could not obtain a global declaration for mystery. The schema also declares known, so replacing the mistaken element name with known makes the supplied document valid. Both versions keep the same envelope and wildcard; the example isolates declaration lookup from ordering.

Three common causes to check first

1. An extension element is misspelled or uses an unsupported vocabulary version. Its namespace satisfies the wildcard, but its expanded name has no matching declaration.
2. The extension schema was not loaded into the schema set. A remote schemaLocation hint does not guarantee that a validator will retrieve it.
3. A local element declaration is mistaken for a global declaration. A declaration nested inside another type does not automatically supply the wildcard’s global lookup target.

Repair and retest

Find the xs:any particle that accepts this child and read both namespace and processContents. Search the loaded schema set for a top-level declaration with the child’s namespace URI and local name. If an external vocabulary is intended, load its real schema and dependencies through the local project loader. Prefer correcting a mistaken name or loading a missing definition over changing strict to skip.

When this is a namespace problem

This is often a vocabulary-loading problem rather than an unbound-prefix problem. A declared prefix only associates a spelling with a URI; it does not load a schema. If the URI differs from the imported schema’s targetNamespace, even an otherwise complete project cannot supply the needed declaration.

System.Xml.Schema: “The … element is not declared”

The tested .NET message says the mystery element is not declared, while libxml2 mentions a strict wildcard. Distinguish this from cvc-elt.1.a at the document root: here envelope was already declared and accepted, and lookup fails only for the wildcard child.

Complete tested XML and XSD pairs

Open either variant in the workbench, then choose Validate XML. Loading an example does not run validation or send documents; server checks require the existing permission checkbox.

These transcripts were captured on 5 November 2026 from the exact files shown below. Download all measured results and SHA-256 hashes.

<envelope>
  <mystery>ok</mystery>
</envelope>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="known" type="xs:string"/>
  <xs:element name="envelope">
    <xs:complexType>
      <xs:sequence>
        <xs:any processContents="strict"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

<envelope>
  <known>ok</known>
</envelope>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="known" type="xs:string"/>
  <xs:element name="envelope">
    <xs:complexType>
      <xs:sequence>
        <xs:any processContents="strict"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'mystery'.

The 'mystery' element is not declared.

Element 'mystery': No matching global element declaration available, but demanded by the strict wildcard.

element 'mystery' not found

Saxon comparison and test scope

Saxonica documents XSD processing as an Enterprise Edition feature. The Saxon rows map the named constraint, rather than presenting an invented message. The four measured rows are Xerces, .NET, the shipped workbench engine and XSDHub’s second engine.

The corrected results apply to these self-contained XSD 1.0 specimens. They do not establish business-rule acceptance for a different document or schema version.

Continue the diagnosis

• cvc-elt.1.a: cannot find the declaration of the root
• src-resolve: the schema reference cannot be resolved
• xsd import include errors

All parser error codes · XML and XSD validator

Primary references

• Apache Xerces message catalogue
• Microsoft: schema validation and identity checks