Back to Updates
DevTool Team

XML Validation Complete Guide: XSD, DTD, API, and CI Workflow

A practical, reader-friendly XML validation guide for developers and testers: syntax checks, XSD/DTD strategy, batch validation, API integration, and CI fail-fast rules.

If XML keeps breaking in production, this is for you

If you're here, you've probably seen one of these:

  • XML parses locally but fails in downstream systems
  • A tiny schema mismatch causes a deployment rollback
  • Batch files are mostly fine, except for a few hidden bad records

This guide gives you a clear workflow you can implement quickly.


The 5-minute version

Use this order every time:

  1. Run syntax validation first
  2. Run XSD or DTD validation (pick one)
  3. Run batch validation before release
  4. Use error codes in CI, not only message text

Start here: Open XML Validator


Step 1: Clean syntax errors first

Do not jump directly to schema checks. If syntax is broken, schema errors become noisy.

Typical example:

<order>
  <item>Apple</item>
  <total>12.5</total>
</orders>

The root open/close tag mismatch must be fixed first.


Step 2: Choose XSD or DTD

Choose XSD when

  • You need strict typing (decimal, date, etc.)
  • You need explicit sequence/cardinality constraints
  • You rely on namespaces

Choose DTD when

  • You maintain legacy XML contracts
  • You need lightweight declaration-based rules

Current DTD flow supports:

  • ELEMENT models (sequence/choice/repeat, EMPTY, ANY, mixed)
  • ATTLIST constraints (#REQUIRED, #FIXED, enum)
  • Internal ENTITY resolution

Example:

<!ENTITY cat "cooking">
<!ELEMENT bookstore (book+)>
<!ELEMENT book (title,price)>
<!ELEMENT title (#PCDATA)>
<!ELEMENT price (#PCDATA)>
<!ATTLIST book category (cooking|children) #REQUIRED>

Step 3: Batch validation before release

Single-file success is not enough.

For release safety, always run a batch check:

  • Validate all candidate XML files
  • Keep per-file errors
  • Fail the pipeline if any file fails

A 1% failure rate can still become a production incident.


Step 4: API integration for CI/CD

Single-file endpoint

curl -X POST https://www.ilovedevtool.com/api/xml/validate \
  -H "Content-Type: application/json" \
  -d '{
    "xml": "<order><item>Apple</item><total>12.5</total></order>",
    "xsd": "<xs:schema .../>"
  }'

Batch endpoint

curl -X POST https://www.ilovedevtool.com/api/xml/validate/jobs \
  -H "Content-Type: application/json" \
  -d '{
    "files": [
      {"fileName":"a.xml","xml":"<order>...</order>","xsd":"<xs:schema .../>"},
      {"fileName":"b.xml","xml":"<bookstore>...</bookstore>","dtd":"<!ELEMENT bookstore ...>"}
    ],
    "options": {"outputFormat":"all"}
  }'

Note: For one file payload, use either xsd or dtd.


Error codes your pipeline should care about

  • XML_INVALID
  • XSD_INVALID
  • SCHEMA_MISMATCH
  • DTD_INVALID
  • DTD_MISMATCH
  • PAYLOAD_TOO_LARGE

Why codes first?

  • Human messages are great for debugging
  • Codes are better for automation and long-term stability

Common mistakes to avoid

  1. Treating “parseable” as “valid for contract”
  2. Ignoring a small number of failed files
  3. Mixing schema styles without a team rule
  4. Putting sensitive production values into test samples

Release checklist (copy this)

  • Syntax validation passed
  • XSD or DTD validation passed (one chain per file)
  • Batch validation passed (failed = 0)
  • CI uses error-code based gates
  • Core payload samples included in regression

Where to go next

  1. Open XML Validator
  2. DTD Landing
  3. API Landing
  4. Samples Library

You do not need to implement everything on day one. Start with syntax + single-file schema checks, then add batch + CI gates.