Why DTDs Become a Problem in Large Archives
DTDs were extremely important for XML publishing. They are simple, readable, fast to process and historically well supported by editorial tools. Many large archives exist precisely because DTD-based workflows were reliable enough for production. The point is not that DTDs were bad. The point is that modern migration projects usually need constraints that DTDs were never designed to express.
A DTD can describe allowed element nesting and attributes, but it has no rich datatype system. A publication date is text. A percentage is text. A language code is text. A controlled editorial status is usually text unless the DTD author enumerated it, and even then the value is often too broad for a specific project. Namespaces are awkward. Cross-document constraints are outside the model. Package-level questions such as “does every image referenced in the XML exist in the package?” cannot be answered by a DTD alone.
XSD improves the structural rule set because it can express datatypes and reusable type definitions. It can say that a value is an xs:date, that a number must be between 0 and 100, that a language code must match a pattern, or that a section type must be selected from a controlled list. This does not make XSD the only validation technology we need. Rather, XSD becomes the structural and datatype layer in a larger validation architecture.
Schematron complements XSD because it validates context. XSD is good at grammar; Schematron is good at rules. A rule such as “graphics must point into the normalized images directory” or “do not allow whitespace before punctuation” is often clearer in Schematron. Link checkers, package validators and dashboards then add further layers.