When specifying both a DTD and XSD for an XML document, validators seem to validate against the XSD and ignore the DTD completely.
I've verified this in XMLSpy 2018sp1 and Xerces' StdInParse tool.
The standard use case for this is that there is an industry standard DTD we reference (and never edit) which me must validate against. Further to this we further constrain the XML ourselves using our own XSD.
My gut feeling is if both are specified, both the DTD and XSD should have to pass validation for the document to be validated? But perhaps XSD is considered to supersede any DTD?
Example XML - in the below - foo.dtd will never be used to validate the document. It passes the document as valid even if it violates foo.dtd, providing it validates against foo.xsd.
If you remove the attributes from <Foo> and validate again against foo.dtd, XMLSpy for example will suddenly pick-up any DTD issues.... put the XSD location back into Foo, and the errors disappear again!
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Foo
SYSTEM "/usr/local/share/xml/schema/foo/foo.dtd">
<Foo xmlns="https://www.foo.com/schema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://www.foo.com/schema /usr/local/share/xml/schema/foo/foo.xsd">
Can anyone confirm what is the correct behavior, if any?
I think Michael's comment above provides good insight.
To round-up, XMLSpy have got back to me and confirmed that in XMLSpy2018sp1, any specified XSD will "win" over a DTD with regards to element and attribute content. There is no current workaround other than to temporarily remove the XSD specification from the XML.
They have put it on their wishlist to be able to control both type and order of validation - but don't hold you're breath, as I accept it's a bit of an edge case. I'd have thought it was an easy feature to add tho!