Troubleshooting

cXML DTD validation failed

The buyer rejects your document with a DTD or schema validation error, often quoting an element name that looks perfectly correct in your output.

Short answer

The cause most people miss: cXML enforces element order. A document containing every required element in the wrong sequence fails validation, and the error names the element it did not expect rather than the one that is out of place — which sends you looking in the wrong direction.

Causes, most likely first

Ordered by how often each one turns out to be the culprit, not by how interesting it is. Work down the list.

  1. Elements are in the wrong order

    How to confirm: Inside ItemDetail the sequence is UnitPrice, Description, UnitOfMeasure, Classification, then the manufacturer elements. Emitting Description before UnitPrice fails, even though both are present and correct.

    Fix: Build documents from a template that fixes the order rather than appending elements as your data arrives. This is the single most common cause of a "but that element is right there" error.

  2. Unescaped characters in text content

    How to confirm: An ampersand in a product description is the classic. "Nuts & bolts" must be "Nuts & bolts". Angle brackets and quotes in attributes cause the same failure.

    Fix: Escape all five XML entities on every value you interpolate. If you are building cXML with string concatenation, this will happen eventually — use a serialiser.

  3. A required attribute is missing

    How to confirm: Money without currency, Classification without domain, ItemIn without quantity. The document reads fine and fails validation.

    Fix: Check the attributes, not just the elements. Our free tester reports each of these individually.

  4. The DOCTYPE or version does not match what the buyer expects

    How to confirm: Buyers pin a cXML version. Declaring a different one, or omitting the DOCTYPE where they require it, fails before any content is examined.

    Fix: Ask which version they validate against and emit exactly that. Do not assume the newest is safest — many buyers are pinned to older releases deliberately.

  5. An element that must not be empty is empty

    How to confirm: An empty Description or Identity is structurally present and semantically invalid. Frequently caused by a null in your data reaching the serialiser.

    Fix: Treat empty as missing at the point you build the document, and fail loudly there rather than sending it.

If it is not on your side

Send the buyer the exact document you produced, redacted, along with the validation error you received. If they validated against a different version than you emitted, this is the fastest way to discover it.

Check the document itself

Paste your cXML or OCI payload into our free tester. It runs entirely in your browser and reports the structural problems buyers reject on.

Open the tester

Related questions

Can I validate against the DTD myself?

Yes, with a validating XML parser and the DTD published at cxml.org. Browsers do not perform DTD validation, which is why our free tester applies the structural rules directly instead — it produces a readable explanation rather than a parser error.

Why does the error name the wrong element?

Because a sequence-based parser reports the first element it did not expect at that position, which is the one after the misplaced one. Read the error as "something before this is out of order" rather than "this element is wrong".

Other failures

Rather not be the one debugging this?

We build and run the endpoint, and deal with the buyer’s technical team directly. Pricing is published in full.

See pricing Send us the error