• Parameter-Entities
• Allgemeine Entities

Entities dienen meist als eine Art Platzhalter für einen Ersatztext oder für Daten, die die Entity repräsentiert. Ein weit verbreitetes Beispiel für eine Entity wurde bereits im vorhergehenden Abschnitt gezeigt: Dort wurde eine Entity definiert, die eine XML-Datei bezeichnet, und der Parser hat den Inhalt dieser Datei dann an der Stelle, an der die Entity im Dokument »aufgerufen« wurde, aufgenommen. Man sagt auch, der Parser hat die Entity expandiert oder aufgelöst.

In XML werden zwei Arten von Entities unterschieden: die allgemeinen Entities und die Parameter-Entities. Diese werden wiederum in Abhängigkeit von ihrer Definition in externe und interne Entities unterschieden. Abbildung 20.4 zeigt die Unterteilung der Typen im Überblick.

Abbildung 20.4: Typen von Entities

Eine detaillierte Kenntnis der Unterschiede zwischen den verschiedenen Entity-Typen ist in der Praxis nicht unbedingt erforderlich, sie ist aber sehr hilfreich, wenn man in Härtefällen die XML-Spezifikation konsultieren will.

Eine Entity heißt genau dann extern, wenn sie mit einer Public- oder einer System-ID definiert ist. Allgemeine externe Entities können optional noch eine Notation referenzieren.

Wie Abbildung 20.4 ebenfalls zu entnehmen ist, wird zwischen analysierten und nicht analysierten Entities unterschieden (»parsed« bzw. »unparsed«). Wie die englischen Begriffe bereits andeuten, wird Inhalt analysierter Entities vom Parser geprüft, der von nicht analysierten Entities dagegen ignoriert und an die Applikation weitergereicht.

Parameter-Entities

Parameter-Entities können ausschließlich innerhalb der DTD verwendet werden und dienen dazu, Definitionen in der DTD zu vereinfachen. Das folgende Beispiel zeigt die Verwendung einer Parameter-Entity am Beispiel einer DTD für ein Buch. Ein Buch bestehe aus Kapiteln, die wieder in Abschnitte unterteilt sind. Sowohl für Kapitel als auch für Abschnitte soll ein Attribut vom Typ ID vorhanden sein, um es für Verweise angeben zu können. Mit einer Parameter-Entity kann man dieses Attribut einmal vereinbaren und dann bei Definitionen aller Elemente, die dieses Attribut erhalten sollen, den Namen dieser Parameter-Entity angeben, anstatt das Attribut jedesmal neu zu spezifizieren.

Das Beispiel könnte ohne Parameter-Entities so aussehen:

  <!ELEMENT CHAPTER (SECTION*)>
  <!ATTLIST ELEMENT ID ID #IMPLIED>

  <!ELEMENT SECTION (...)>  
  <!ATTLIST SECTION ID ID #IMPLIED>

Hier bietet es sich an, die Definition des Attributs ID in einer Parameter-Entity vorzunehmen, die dann in den ATTLIST-Definitionen referenziert wird:

  <!ENTITY % REFID " ID ID #IMPLIED">

  <!ELEMENT CHAPTER (SECTION*)>
  <!ATTLIST ELEMENT %REFID;>

  <!ELEMENT SECTION (...)>  
  <!ATTLIST SECTION %REFID;>

Wie man sieht, wird die Definition einer Parameter-Entity mit einem Prozentzeichen eingeleitet. Die Referenzierung erfolgt ebenfalls mit einem Prozentzeichen und nicht mit einem kaufmännischem Und (&) wie bei allgemeinen Entities.

Diese Lösung ist zum einen durch den sprechenden Namen der Parameter-Entity besser lesbar, zum anderen werden Änderungen an der DTD deutlich vereinfacht, weil sie nur an einer Stelle angebracht werden müssen.

Da eine Parameter-Entity nicht nur so wie in diesem Beispiel einen Teil einer Attribut-Definition, sondern auch komplette Element-Definitionen beeinhalten kann, können DTDs mit Parameter-Entities gut modularisiert werden. Die DTD von HTML macht extensiven Gebrauch von Parameter-Entities und mag dem Leser daher als weiteres Beispiel dienen.

Das gezeigte Beispiel demonstrierte die internen Parameter-Entities. Externe Parameter-Entities werden dazu benutzt, in einer DTD Definitionen, die in externen Dateien liegen, gewissermaßen als Module hinzuzuladen. Angenommen, die Datei bib.dtd enthält Definitionen zur Auszeichnung einer Bibliographie. Dann werden diese Definitionen mit folgender Sequenz in eine andere DTD eingebunden:

  <!ENTITY % BIB-DTD SYSTEM "bib.dtd">
  %BIB-DTD;

Die Elemente der hinzugeladenen Datei müssen danach in die Elemente der DTD integriert werden. Wenn BIBLIOGRAPHY das »äußerste« Element ist, das in bib.dtd definiert ist, könnte dies in einer DTD für ein Buch folgendermaßen aussehen:

  <!ELEMENT BOOK (CHAPTER+, BIBLIOGRAPHY?)>

Allgemeine Entities

Wie bei den Parameter-Entities wird auch bei den allgemeinen Entities zwischen internen und externen Entities unterschieden.

Die internen allgemeinen Entities sind hierbei der einfachste Entity-Typ. Er definiert lediglich einen Namen für einen Ersatztext, der vom Parser expandiert wird. Anwendungsfälle sind oft benötigte und recht lange Textfragmente.

<!ENTITY dpunkt "dpunkt.Verlag für digitale Technologie">

Innerhalb des Dokuments kann die Entity dann aufgerufen werden:

Erschienen bei: &dpunkt;.

Dieser Entity-Typ wird normalerweise bereits vom Parser expandiert (obwohl die Spezifikation dies nicht vorschreibt), so dass die Applikation nicht mehr feststellen kann, ob ein Text direkt im Dokument stand oder ob an der betreffenden Stelle eine Entity-Referenz stand.

Externe allgemeine Entites werden dazu benutzt, um den Inhalt externer Dateien (wohl hauptsächlich XML-Dateien) in einem Dokument zu referenzieren. Externe Entites sind entweder mit einer System- oder Public-IDs definiert. In Abschnitt 20.5.3 wurde bereits beschrieben, wie externe Dateien mit diesem Entity-Typ eingebunden werden.

Abbildung 20.5 zeigt, wie der Parser eine Entity auf eine externe Datei auflöst und ihren Inhalt in den Parse-Baum integriert. Die von der Entity referenzierte Datei wird geladen und geparst, und danach wird der Entity-Knoten durch den Teilbaum des externen Dokuments ersetzt.

Abbildung 20.5: Auflösen einer externen allgemeinen Entity

Das DOM- und das SAX-API bieten die Möglichkeit, die Aktionen zum Auflösen von Entities selbst zu implementieren. Hierdurch hat man eine weitgehende Kontrolle über die Expandierung von Entities. Bei neueren Parsern ist konfigurierbar, ob der Parser bereits die Auflösung vornimmt und die Applikation somit gar nichts von der Entity mitbekommt oder ob externe Entities ohne Auflösung als eigenständige Knoten an die Applikation durchgereicht werden sollen.