XML vs XSD: what each check tells you
Published by XSDHub · How our guides and examples are made
XML carries the data
XML is a text-based format for representing structured information. Elements, attributes and namespaces give a document its shape. For example, <quantity>two</quantity> is well-formed XML: the start and end tags match and the text is allowed. At this level, XML does not know whether the receiving application expects a number.
XSD describes permitted structure
An XSD is a separate schema written in XML. It can declare quantity as xs:positiveInteger, require an order identifier, and specify the sequence of customer and item fields. Against that schema, quantity containing two is invalid; quantity containing 2 can pass. The schema determines the rule, not the field name alone.
Check syntax before schema conformance
First make the XML well-formed. Then compile and apply the exact XSD version expected by the receiving system. Finally check application rules that go beyond the schema, such as whether a calculated invoice total matches its line items. Passing one layer does not imply the next layer passes.
Namespaces identify vocabulary
A namespace URI is part of an element name. An order in urn:example:orders is not the same element as an order without that namespace. Prefixes such as xs and xsd are labels bound to namespace URIs; choosing a different prefix does not itself change the underlying name. When debugging, compare the namespace bindings and targetNamespace as well as the visible tag text.
Choose the smallest check that answers the question
Use an XML validator for broken tags and quoting problems, an XSD validator for structure and typed values, and a formatter to inspect a dense document. For multi-file XSD 1.0 schemas, load the complete folder or ZIP into the project loader. Choose the optional server engine for XSD 1.1 assertions or ISO Schematron XPath 1.0 rules; this uploads the inputs with your permission.