Fazit

Diese Einführung hat gezeigt, dass XSD in der Tat deutlich mehr kann
als XML-DTDs. Um alle Möglichkeiten von XSD auszuschöpfen,
sind allerdings auch weit umfangreichere Kenntnisse erforderlich.
Wenn man eine DTD und die entsprechende XSD vergleicht, sieht man
auf den ersten Blick, dass eine XSD bei gleichem Informationsgehalt viel mehr Zeichen benötigt, und auch, dass sie sich viel schlechter lesen lässt.
Das liegt neben der puren Zeichenmenge an der umständlichen XML-Syntax, und hier besonders daran, dass zentrale Informationen als Attributwerte
angeben sind. So fallen sie bei weitem nicht so deutlich ins Auge
wie z. B. Elementnamen bei Deklarationen in DTD-Syntax. Auch die
hierarchischen Strukturen, die mit allerlei XSD-Container-Elementen
durchsetzt sind, können vom menschlichen Auge nicht mehr intuitiv
wahrgenommen werden.
Das alles sind natürlich auch Fehlerquellen, die den Aufwand,
der für die Erstellung einer XSD notwendig ist, in die Höhe treiben.
Dieser Aufwand setzt sich bei notwendigen Modifikationen fort.
Der Preis für die Nutzung der Möglichkeiten von XSD ist also
ein höherer Aufwand in der Schema-Pflege, jedenfalls dann,
wenn man den Anspruch hat, eine XSD im Quelltext zu erstellen.
Dieser Aufwand lässt sich freilich durch die Verwendung
von Tricks und Tools wieder auf ein akzeptables Maß vermindern.
Wie es für DTDs Editoren mit graphischer Oberfläche gibt, gibt es
Editoren auch für die graphische Bearbeitung von XSDs. Mit ihnen
können leicht und ohne viel Aufwand XSDs erstellt werden,
die einer vergleichbaren DTD überlegen sind.
Auch kann man zuerst eine DTD erstellen, diese mit einem Tool
in eine XSD konvertieren und erst dann die XSD-spezifischen Erweiterungen hinzufügen.
Ab einem gewissen Komplexitätsgrad sind freilich auch gute XSD-Editoren überfordert und der Bearbeiter muss den Quelltext direkt bearbeiten.
Dann sind vergleichbar komplexe DTDs sicher einfacher zu pflegen.
Als KO-Kriterium gilt allerdings, dass nur XSDs mit XML-Werkzeugen
wie Transformations-Prozessoren bearbeitet werden können. Wer also
eine automatische Modifikation seiner XML-Struktur-Definitionen benötigt,
ist mit XSD weit besser bedient.
Der vollständigen Umstellung eines XML-Workflows auf XSD sollte
eine sorgfältige Analyse der folgenden Punke vorausgehen:
- Dringlichkeit:
  Wie sehr benötige ich Erweiterungen, die XSD bietet?
- Pflegeaufwand:
  Kann ich meine XSDs mit einem graphischen XSD-Editor pflegen oder
  würden sie so komplex ausfallen, dass aufwändige manuelle Pflege nötig wird?
- Software-Unterstützung:
  Unterstützen alle Programme im Workflow eine Validierung mit XSD?
- Automatisierungsgrad:
  Würden eine automatisierte XSD-Erstellung und automatisierte Modifikationen meinen Workflow erheblich erleichtern?
- Alternative Lösungen:
  Wenn einige der vorstehenden Aspekte gegen XSD sprechen: Kann ich
  die zusätzlichen Kontrollmöglichkeiten, die mir XSD bietet, evtl. mit Hilfe
  eigener Skripte oder mit SGML-Mitteln mit geringerem Gesamtaufwand realisieren?
Bei laufenden Projekten kann es sinnvoll sein, XSD als zusätzliches
Validierungsmittel während der Erstellung und Änderung von XML-Daten
durch menschliche Bearbeiter einzusetzen, um die hier besonders häufigen Fehler abzufangen. Für diesen Zweck können schon vorhandene DTDs
nach XSD konvertiert werden und mit wenig Aufwand um XSD-spezifische Erweiterungen ergänzt werden.
An der Zukunft von XSD als DTD-Nachfolger kann es kaum Zweifel geben.
Die Nutzung von XML im WWW nimmt beständig zu, und da viele XML-Web-
Anwendungen den im Hintergrund laufenden Datenaustausch betreffen,
ist XSD das Mittel der Wahl, wenn es um die Validierung dieser Daten geht.
Mittlerweile unterstützen alle namhaften XML-Software-Produkte XSD.
Auch Publishing-Software, die XML auf ihre Fahnen schreibt (und welche tut das derzeit nicht?), wird sich dieser Entwicklung auf Dauer nicht entziehen können.