Oft kann in der XML-Welt die Datenstruktur in der DTD nicht so präzise definiert werden, wie es eigentlich wünschenswert wäre. In SGML hingegen gibt es wesentlich mehr Möglichkeiten. Die Ursachen hierfür liegen zu einem guten Teil in den konzeptionellen Grenzen von XML selbst.

Die Konsequenz in der Praxis ist: Anstelle technisch klar definierter Strukturen und Regeln, wie sie in SGML möglich sind, treten bei XML »Best Practice«-Papiere, die beschreiben, wie mit den gegebenen Strukturen zu verfahren ist.

Die Erfahrung zeigt jedoch: wo Fehler möglich sind und zuverlässige Kontroll-Instrumente fehlen, wird es auch Fehler geben. Diese werden früher oder später die Produktqualität verschlechtern und müssen dann nachträglich mit hohem Aufwand behoben werden. Spätestens wenn bei bestimmten Ausgabewegen (z. B. CD-Retrieval-Software) »seltsame Effekte« auftreten, die auf »kreativer Gestaltung« der XML-Daten beruhen, wird man sich Gedanken über zuverlässigere Kontroll-Instrumente machen müssen.

Das Problem ist: Viele Aspekte in XML-Daten, die man gerne systematisch überprüfen möchte, können mit normalen XML-DTD-Parsern gar nicht überprüft werden. Das betrifft den Inhalt von bestimmten Attributen genauso wie bestimmte Strukturmerkmale. Um dennoch eine systematische Kontrolle durchzuführen, bieten sich drei Lösungen an: XML-Schema benutzen, SGML-Mittel verwenden oder eigene Kontroll-Skripte programmieren.

Diese drei Lösungswege unterscheiden sich stark vom Aufwand her.

In der Regel liegen heute die XML-Struktur-Definitionen als DTD vor, seltener als XML-Schema (XSD). XSD ist ein relativ neuer Standard für XML-Struktur-Definitionen und wird zukünftig bei komplexen Strukturdefinitionen die DTD ablösen. Ein Schema bietet weiter gehende Möglichkeiten der Strukturkontrolle; allerdings ist die Erstellung eines Schemas auch weit aufwändiger als die Erweiterung einer DTD. XML-Schema ist im Verlagsbereich bislang nur sehr wenig verbreitet.

Eine XML-DTD kann hingegen sehr einfach mit SGML-Features angereichert werden, ohne dass dies den sonstigen XML-Workflow stört. Man nutzt dabei die Tatsache, dass ein XML-Dokument immer auch ein SGML-Dokument ist.

Mit eigenen Skripten können Sie alles Denkbare kontrollieren, allerdings ist auch der Aufwand sehr hoch.

Wir wollen Ihnen für alle drei Lösungswege Beispiele geben. In diesem ersten Beitrag zu dem Thema soll es zunächst um SGML-Konstruktionen als temporäre XML-Erweiterungen gehen.

Die Verwendung von SGML-Konstruktionen bietet sich bei einer Reihe von Punkten im Produktionsprozess an. Am sinnvollsten ist sie bei Arbeitsschritten, bei denen Daten umfangreich geändert werden, da hier die Fehleranfälligkeit am größten ist. In der Verlagsbranche sind das Erfassung, redaktionelle Bearbeitung und Korrekturausführung sowie der Satz.

Hier können menschliche Bearbeiter, eher an layout- als strukturorientiertes Arbeiten gewohnt, viele und vielfältige Fehler machen. Beim Satz müssen die Ausgangsdaten oft in einen dem Ausgabemedium Print entsprechenden Datenstrom transformiert werden. Korrekturen nach dieser Transformation – also während der Satzphase – sind die Regel. Will man Doppelpflege in Satzdaten und Ausgangs-XML vermeiden, muss man die korrigierten Daten nach dem Satz wieder in die Ausgangsform zurück transformieren. Dabei ist möglichst genaues Parsen eines der wichtigsten Instrumente zur Qualitätssicherung.

Voraussetzung für die Nutzung von SGML ist die Verfügbarkeit entsprechender Software. Wenn Sie Einfluss auf die Verwendung von XML-Editoren bei Autoren, in der Redaktion oder beim Satzbetrieb (Korrekturausführung in XML!) haben, können Sie dafür sorgen, dass SGML-fähige Profitools verwendet werden. Ist das nicht durchweg realisierbar, kann wenigstens an neuralgischen Punkten zusätzlich mit SGML geparst wird.

So kann durch genauer definierte SGML-Inhaltsmodelle die Einhaltung der gewünschten Strukturen in den XML-Daten besser kontrolliert werden. Und genauer definierte Daten sind immer sicherer zu verarbeiten und zudem werthaltiger als ungenau strukturierte.

Im Prinzip gilt: es sollte an so vielen Stellen im Produktionsprozess so restriktiv (d. h. streng, scharf) wie möglich geparst werden. Sollte das nur begrenzt möglich sein, ist es umso wichtiger, an wenigen, aber entscheidenden Punkten des Produktionsprozesses restriktiv zu parsen. Das gilt zumindest und in erster Linie für die Punkte, an denen die Daten von einer Produktionsphase in eine andere übergehen (Datenübergabe vom Autor zur Redaktion, von der Redaktion zum Satz, vom Satz zum Verlag).

Fazit