Warum DTDs in großen Archiven zum Problem werden
DTDs waren für XML-Publishing außerordentlich wichtig. Sie sind einfach, lesbar, schnell zu verarbeiten und wurden historisch von Redaktionswerkzeugen sehr gut unterstützt. Viele große Archive existieren gerade deshalb, weil DTD-basierte Workflows zuverlässig genug für die Produktion waren. Der Punkt ist nicht, dass DTDs schlecht waren. Der Punkt ist, dass moderne Migrationsprojekte meistens Constraints benötigen, für die DTDs nie entworfen wurden.
Eine DTD kann erlaubte Elementverschachtelungen und Attribute beschreiben, besitzt aber kein reiches Datentypsystem. Ein Publikationsdatum ist Text. Ein Prozentwert ist Text. Ein Sprachcode ist Text. Ein kontrollierter redaktioneller Status ist meistens Text, sofern der DTD-Autor ihn nicht enumeriert hat, und selbst dann ist der Wertbereich für ein konkretes Projekt oft zu breit. Namespaces sind umständlich. Dokumentübergreifende Constraints liegen außerhalb des Modells. Paketbezogene Fragen wie "Existiert jedes Bild, das im XML referenziert wird, auch im Paket?" lassen sich mit einer DTD allein nicht beantworten.
XSD verbessert das strukturelle Regelwerk, weil es Datentypen und wiederverwendbare Typdefinitionen ausdrücken kann. Es kann festlegen, dass ein Wert ein xs:date ist, dass eine Zahl zwischen 0 und 100 liegen muss, dass ein Sprachcode einem Pattern entsprechen muss oder dass ein Abschnittstyp aus einer kontrollierten Liste gewählt wird. Das macht XSD nicht zur einzigen Validierungstechnologie, die wir brauchen. Vielmehr wird XSD zur Struktur- und Datentypschicht innerhalb einer größeren Validierungsarchitektur.
Schematron ergänzt XSD, weil es Kontext validiert. XSD ist stark bei Grammatik; Schematron ist stark bei Regeln. Eine Regel wie "Grafiken müssen in das normalisierte Bilderverzeichnis zeigen" oder "Vor Satzzeichen darf kein Leerzeichen stehen" ist in Schematron oft klarer. Linkchecker, Paketvalidatoren und Dashboards ergänzen weitere Schichten.