Well-formed XML vs. XSD-valid XML

Two checks answer different questions

A parse check asks whether the document can be read as XML. A schema check asks whether that document has the shape and values expected by a particular contract. Keep those results separate when debugging an integration.

Suppose a warehouse expects a quantity as an integer. A quantity containing the word five is readable XML, but it does not meet that data-type requirement.

<!-- Well-formed, but not valid against the schema below -->
<quantity>five</quantity>

<!-- Well-formed and valid against the schema below -->
<quantity>5</quantity>

Try a complete, self-contained schema

Save this as quantity.xsd and save either example as quantity.xml. The schema declares one unnamespaced quantity element with an integer type. Validate each document against this same schema to see the difference.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="quantity" type="xs:integer"/>
</xs:schema>

Check syntax before schema rules

Use this order when investigating a rejected file. It keeps syntax problems from obscuring schema problems.

<!-- Syntax failure: the names do not match -->
<quantity>5</amount>

• Open a copy of the XML and fix any parse errors first.
• Select the schema expected by the receiving system—not simply a similarly named XSD.
• Validate the document and inspect each reported element or value.
• Correct the source, validate again, and review the final file before sending it.

Compiling an XSD is a separate operation

Checking a schema itself does not validate every document that will use it. In XML Lens, XSD Viewer helps you inspect and compile a self-contained schema; the validation workspace checks an XML document against a selected XSD.

If a document unexpectedly fails, check the schema version and namespace as well as the data. A different contract may require different element names, ordering, or fields.

A schema pass is not a business approval

The sample schema also accepts a negative integer. Whether a warehouse should accept a negative quantity is a business decision; this schema does not restrict it. Add the appropriate schema restriction or downstream check when that rule matters.

Keep a small set of representative documents: one expected to pass and several expected to fail for different reasons. Run them when the schema changes so a new rule does not silently change the contract.

Common questions

Try the workflow in XML Lens

Explore the relevant Mac workspaces and their capabilities.