XSD validation error
This element is not expected
An element appeared where the schema's content model does not allow one — an extra child, an unknown child, or the right children in the wrong order.
Element 'note': This element is not expected. (line 10)What it means
An xs:sequence is ordered and closed. The validator walks the children in document order, and the moment one does not fit the position it has reached, it stops and reports that element — which is why the element named is often innocent and the real fault is the one before it.
Three different mistakes produce this one message: an element that does not belong at all, one that belongs but appears too many times, and two elements that belong but are the wrong way round. The message does not distinguish them; the schema's sequence does.
What usually causes it
- A sender adding a field, exactly as with an undeclared attribute.
- Elements emitted in object-property order rather than schema order — an xs:sequence requires the schema's order.
- More repetitions than maxOccurs permits.
- A missing element earlier in the sequence, which shifts everything after it out of position.
How to fix it
- Compare the document's child order against the xs:sequence, element by element, from the top.
- If the order is the problem, either reorder the output or change the schema to xs:all, which permits any order.
- For documents meant to be extended, add <xs:any namespace="##other" processContents="lax"/> so unknown children are allowed deliberately.
- Check whether an earlier element is missing before assuming the reported one is wrong.
The same error elsewhere
libxml2 words these plainly. Xerces numbers them, and those cvc- codes are what most people end up searching for.
Xerces (Java)
cvc-complex-type.2.4.a: Invalid content was found starting with element 'note'. One of '{line}' is expected..NET System.Xml
The element 'order' has invalid child element 'note'.
Before and after
Both documents below are well-formed XML — that is the point. The test suite re-checks them against the real validator on every build: the first is confirmed to produce the exact message above, the second to validate cleanly.
<?xml version="1.0" encoding="UTF-8"?>
<order id="A-1">
<customer>Ada</customer>
<issued>2026-01-31</issued>
<state>open</state>
<line>
<code>AB-1234</code>
<qty>2</qty>
</line>
<note>hi</note>
</order>
<?xml version="1.0" encoding="UTF-8"?>
<order id="A-1">
<customer>Ada</customer>
<issued>2026-01-31</issued>
<state>open</state>
<line>
<code>AB-1234</code>
<qty>2</qty>
</line>
</order>
The schema both are checked against
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="status">
<xs:restriction base="xs:string">
<xs:enumeration value="open"/>
<xs:enumeration value="closed"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="sku">
<xs:restriction base="xs:string">
<xs:pattern value="[A-Z]{2}-\d{4}"/>
</xs:restriction>
</xs:simpleType>
<xs:element name="order">
<xs:complexType>
<xs:sequence>
<xs:element name="customer" type="xs:string"/>
<xs:element name="issued" type="xs:date"/>
<xs:element name="state" type="status"/>
<xs:element name="line" minOccurs="1" maxOccurs="2">
<xs:complexType>
<xs:sequence>
<xs:element name="code" type="sku"/>
<xs:element name="qty" type="xs:positiveInteger"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
Where this bites most
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.