Skip to main content

XSD validation error

The value is not an element of the set

The value is not one of the permitted options. The message lists the full set, which makes it the one schema error that tells you the answer outright.

Element 'state': [facet 'enumeration'] The value 'pending' is not an element of the set {'open', 'closed'}. (line 5)

What it means

An xs:enumeration restriction fixes a closed vocabulary — a status, a currency, a country code. Any value outside it is invalid regardless of how sensible it looks, and the validator prints the whole permitted set alongside the rejection.

Case matters. 'Open' is not 'open', and neither is ' open' with a leading space, because enumeration compares the value after whitespace processing rather than loosely.

What usually causes it

  • An internal status vocabulary that has grown a value the schema was never told about.
  • Case or whitespace differences between the sender's value and the schema's.
  • A code list version mismatch — the sender is on a newer edition with more values.
  • A translated or display value sent instead of the machine value.

How to fix it

  • Use one of the values named in the message; the set is printed in full.
  • If the new value is legitimate, revise the schema and version it — silently widening a code list breaks every consumer validating against the old one.
  • Map internal vocabularies to the schema's at the boundary, not by hoping they coincide.

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-enumeration-valid: Value 'pending' is not facet-valid with respect to enumeration '[open, closed]'. It must be a value from the enumeration.
  • .NET System.Xml

    The 'state' element is invalid - The value 'pending' is invalid according to its datatype 'status' - The Enumeration constraint failed.

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.

Fails validation
<?xml version="1.0" encoding="UTF-8"?>
<order id="A-1">
  <customer>Ada</customer>
  <issued>2026-01-31</issued>
  <state>pending</state>
  <line>
    <code>AB-1234</code>
    <qty>2</qty>
  </line>
</order>
Validates
<?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

order.xsd
<?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.