13.2.1 Dokumentanalyse

Der erste Schritt auf dem Weg zur eigenen DTD besteht in der genauen Analyse der zu beschreibenden Dokumentklasse. Welche Vorgehensweise Sie hierbei wählen sollten, hängt stark von dem speziellen Einsatzgebiet ab. Sprechen Sie mit allen beteiligten Personen. Dazu gehören in jedem Fall die Endbenutzer (also die Autoren). Den Benutzern fällt es oft leichter, Mängel in einer DTD festzustellen, als den Dokumenttyp konstruktiv zu beschreiben. Es ist also hilfreich, den Anwendern einen ersten Entwurf der DTD zum Experimentieren zu geben. Sollen die XML-Instanzen später in eine Datenbank integriert werden? Dann ziehen Sie auch Ihren Datenbankfachmann zu Rate. Sprechen Sie mit Ihrem Setzer oder dem Programmierer, der vielleicht einen Konverter schreiben soll. Jede einzelne der beteiligten Personen kann eine andere Sichtweise haben, die es zu berücksichtigen gilt.

Neben diesen allgemeinen Hinweisen versuchen wir, durch die folgende Diskussion eine Art Anleitung zu geben. Als Einstieg soll die Frage dienen, was eine DTD und der Entwurf einer solchen eigentlich ist. Nach den vorangegangenen Kapiteln wissen Sie natürlich schon, wozu eine DTD dient. Sie beschreibt eine Klasse von gleichartigen Dokumenten. Demnach besteht der erste Ansatz beim DTD-Entwurf darin, eine Beschreibung zu finden. Dies ist sicherlich auch eine gute Vorgehensweise, aber wir wollen Ihnen einmal einen alternativen Blickwinkel vorstellen.

Dazu nehmen wir an, dass es in der Menge aller möglichen DTDs die eine gibt, die genau auf Ihre Bedürfnisse zugeschnitten ist. Die Aufgabe lautet dann nicht mehr, eine Klasse von Dokumenten zu beschreiben, um eine DTD zu entwerfen; jetzt geht es darum, jene eine optimale DTD zu finden. Nun wollen wir Ihnen nicht vorschlagen, alle möglichen DTDs herzunehmen und wie nach der Nadel im Heuhaufen Ihre zu suchen. Es geht nur um den Gedankengang.

Wo soll man mit der Suche beginnen und wie soll man vorgehen? — Es ist immer hilfreich, ein konkretes Dokument, vielleicht auch in Form einer wohlgeformten XML-Instanz, als Ausgangspunkt zu betrachten. Dazu eine DTD zu finden ist leicht: Man nimmt einfach die Elemente in genau der Verschachtelung, wie sie in der Instanz stehen, als Dokumenttyp-Definition. Das folgende Beispiel veranschaulicht das:

<?xml version="1.0"?>
<buch>
  <kapitel>
     <ueberschrift>Einleitung</ueberschrift>
     <absatz>...</absatz>
  </kapitel>
  <kapitel>
     <ueberschrift>Beschreibung</ueberschrift>
     <absatz>...</absatz>
  </kapitel>
  <kapitel>
     <ueberschrift>Schlußfolgerung</ueberschrift>
     <absatz>...</absatz>
  </kapitel>
</buch>

Die obige wohlgeformte XML-Instanz soll ein konkretes Buch sein. Wenn man von diesem Beispiel ausgeht, erhält man unmittelbar die folgende DTD.

<!ELEMENT buch         (kapitel, kapitel, kapitel) >
<!ELEMENT kapitel      (ueberschrift, absatz)      >
<!ELEMENT ueberschrift (#PCDATA)                   >
<!ELEMENT absatz       (#PCDATA)                   >

Zugegeben, die DTD ist nicht besonders gut. Man könnte sagen, sie passt zu gut. Ihr zufolge besteht ein Buch immer aus genau drei Kapiteln. Pessimistisch formuliert heißt das: Sie haben nun eine schlechte DTD. Optimistisch betrachtet bedeutet dies: Sie haben eine DTD! Sie ist nur ein wenig zu speziell.

Versuchen wir es von der anderen Seite: mit einer generellen DTD. Was ist das generellste, das man über ein Dokument sagen kann? Eben dass es ein Dokument ist. — Auch dafür findet man leicht eine DTD. Wir zeigen sie gleich mit einer Instanz:

<?xml version="1.0"?>
<!DOCTYPE dokument [
  <!ELEMENT dokument (#PCDATA)>
]>
<dokument>
Dies ist ein Beispiel für eine DTD, die
nur einen einzigen Elementtyp kennt.
Keine sehr große Hilfe :-(
</dokument>

Auch hier müssen wir eingestehen, dass die DTD nicht überzeugt. Ein eher absurdes Beispiel. Diese DTD kann man ohne Übertreibung als etwas zu generell bezeichnen. Aber wir haben Ihnen damit die beiden Extreme gezeigt. Irgendwo dazwischen liegt die passende DTD (vgl. Abbildung 53).

Abbildung 53: Die Suche nach einer DTD: Ausgehend vom allgemeinen Fall oder von einer konkreten Instanz

Welchen Startpunkt soll man wählen, eine zu spezielle oder eine zu generelle DTD? Beginnen Sie mit einer zu generellen DTD, taucht schnell ein Problem auf: Sie werden feststellen, dass Sie gern noch das eine oder andere Element hinzufügen möchten. Zum Beispiel soll ein dokument aus einer Folge von Absätzen bestehen. Erst darin darf Text stehen.

<?xml version="1.0"?>
<!DOCTYPE dokument [
  <!ELEMENT dokument (absatz+)>
  <!ELEMENT absatz   (#PCDATA)>
]>
<dokument>
Dies ist ein Beispiel für eine DTD, die
nur einen einzigen Elementtyp kennt.
Keine sehr große Hilfe :-(
</dokument>

Mit obigem Beispiel stehen wir schlecht da: Die vorhandenen Instanzen passen nun nicht mehr zu der geänderten DTD (weil innerhalb von dokument jetzt kein Text mehr erlaubt ist). Also müssten alle Instanzen geändert werden. Wenn Sie bereits viele Texte geschrieben haben, ist das nahezu unmöglich.

Was passiert aber im Fall der zu speziellen DTD? Stellen Sie sich vor, Sie schreiben ein weiteres Buch mit vier Kapiteln. Auch hier ist eine Änderung der DTD nötig, die etwa folgendermaßen aussehen kann:

<!ELEMENT buch         (kapitel, kapitel, 
                        kapitel, kapitel?)         >
<!ELEMENT kapitel      (ueberschrift, absatz)      >
<!ELEMENT ueberschrift (#PCDATA)                   >
<!ELEMENT absatz       (#PCDATA)                   >

Jetzt hat der Verfasser die Wahl zwischen drei und vier Kapiteln. Spätestens an dieser Stelle sollte man etwas gesunden Menschenverstand einsetzen und die Kapitelzahl offen gestalten.

<!ELEMENT buch         (kapitel+)                  >
<!ELEMENT kapitel      (ueberschrift, absatz)      >
<!ELEMENT ueberschrift (#PCDATA)                   >
<!ELEMENT absatz       (#PCDATA)                   >

Hier ist nun schließlich gestattet, dass ein Buch ein oder mehr Kapitel besitzt. Der große Vorteil: Die erste Instanz mit drei Kapiteln passt immer noch! Was will man mehr? Wir fassen die Ergebnisse in folgenden Tipps zusammen:

Hierarchien von Elementtypen
Die meisten Text-Dokumente, mit denen man üblicherweise zu tun hat, sind sequenzielle Texte, die in der Regel für den Ausdruck oder den Bildschirm konzipiert sind. In der Formatierung bestehen sie aus Textblöcken, die jeweils untereinander stehen. Beispiele dafür sind Absätze, Überschriften, Abbildungen und so weiter. In einem Block befinden sich Textauszeichnungen auf Zeichenebene (Akronym, Personenname, Hervorhebung usw.). Zusammen mit den schon häufig genannten Gliederungselementen (Kapitel, Abschnitt usw.) haben wir nun schon drei Klassen, um Elemente hierarchisch zu gliedern.

Meist ist es so, dass Elemente der Gliederungsebene Blöcke aufnehmen dürfen (ein Kapitel enthält Absätze, Überschriften usw.). Elemente der Blockebene dürfen Zeichenelemente aufnehmen (in einem Absatz stehen Hervorhebungen, Akronyme usw.).