XSD validation error
Not a valid value of the atomic type
The element's text does not fit its declared datatype. Dates are the usual culprit, because XSD accepts exactly one format and humans write several.
Element 'issued': '31/01/2026' is not a valid value of the atomic type 'xs:date'. (line 4)What it means
xs:date means ISO 8601 — YYYY-MM-DD — and nothing else. 31/01/2026 is not a valid date in the wrong format; it is not a date at all as far as the schema is concerned. The same strictness applies to xs:dateTime, xs:boolean (true/false/1/0 only, never TRUE or yes) and every numeric type.
An empty element fails the same way: '' is not a valid xs:date. If a field is genuinely optional, the schema has to say so, because emptiness is not a value any atomic type accepts.
What usually causes it
- A locale-formatted date reaching the serializer — 31/01/2026, 01.31.2026, Jan 31 2026.
- A timestamp written where a date is declared, or the reverse.
- An empty string emitted for a missing optional value.
- Thousands separators or currency symbols in a numeric field.
- A boolean rendered as Yes, TRUE or Y.
How to fix it
- Format dates as YYYY-MM-DD and timestamps as YYYY-MM-DDThh:mm:ss with an offset — always ISO 8601, never the local convention.
- For an optional field, use minOccurs="0" and omit the element, or declare it nillable and send xsi:nil="true". Do not send an empty one.
- Serialize with a type-aware library rather than interpolating strings; the format is the library's job.
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-datatype-valid.1.2.1: '31/01/2026' is not a valid value for 'date'.Xerces (Java, element context)
cvc-type.3.1.3: The value '31/01/2026' of element 'issued' is not valid..NET System.Xml
The 'issued' element is invalid - The value '31/01/2026' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:date'.
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>31/01/2026</issued>
<state>open</state>
<line>
<code>AB-1234</code>
<qty>2</qty>
</line>
</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.