Kompaktkurs XML

XML Syntax, Teil 3: Entities

Ziel

• Entities entsprechen Macros (und auch Include-Dateien) in Programmiersprachen wie C. Der Name eines Entities ist eine Abkürzung, die vom XML-Prozessor automatisch durch den Inhalt des Entities ersetzt wird.
• Man kann ein Entity wie in folgendem Beispiel definieren:

  <!ENTITY email "sbrass@sis.pitt.edu">

  Dann würde überall im Dokument die Entity-Referenz &email; automatisch durch den Text ``sbrass@sis.pitt.edu'' ersetzt.
• Das ist z.B. nützlich, wenn sich die Email-Adresse ändert. Man muß sie dann nur an einer Stelle ändern (in der Entity-Deklaration), und nicht das ganze Dokument durchsuchen, um alle Vorkommen zu ersetzen. Außerdem können Entities Tipparbeit sparen und die Einheitlichkeit erhöhen. Entities wie < sind auch wesentlich lesbarer als direkt < zu schreiben.
• Es gibt in XML verschiedene Arten von Entities. Entities können ``internal'' oder ``external'', ``parsed'' oder ``unparsed'', und ``general'' oder ``parameter'' sein. Von den 8 theoretisch möglichen Kombinationen sind aber nur 5 wirklich erlaubt: ``unparsed'' Entities müssen immer ``external'' und ``general'' sein.
• Das obige Beispiel ist ein ``internal parsed general'' Entity. Ein Entity wäre ``external'' wenn der Inhalt nicht direkt in der Entity-Definition steht, sondern in einer anderen Datei (damit bekommt man den #include-Mechanismus von C). Ein Entity wäre ``unparsed'', wenn es sich nicht um XML handelt, sondern etwa um GIF-Daten. Ein Entity ist ein Parameter-Entity, wenn es für die DTD gedacht ist, und nur dort ersetzt wird.
• In XML redet man weniger von Dateien, als mehr von Entities. So ist in der XML Spezifikation das Kapiel 4, das von Entities handelt, mit ``Physical Structures'' überschrieben. Entities sind also die Container für XML und andere Daten (``storage units''). Die Haupt-Datei, mit der die Auswertung von XML beginnt (und die dann möglicherweise andere Datein läd), heißt auch das ``Document Entity''.

Parameter Entities

• Parameter Entities sind Makros/Abkürzungen, die in der DTD verwendet werden. Sie werden von ``General Entities'' für das Dokument unterschieden, damit der DTD Entwickler diese Entities nicht für den späteren DTD Benutzer dokumentieren muß. Es wäre ja möglich, daß der DTD Benutzer Entities gleichen Namens definieren möchte. Parameter Entities und General Entities werden in unterschiedlichen ``Namespaces'' abgelegt. Es kann also sehr wohl ein Parameter Entity und ein General Entity des gleichen Namens geben.
• Parameter Entities werden folgendermaßen definiert:

  <!ENTITY % font-elems "EM | STRONG | KBD">

  Sie werden dann referenziert (aufgerufen) mit ``%font-elems;''.
• Parameter Entities k"onnen nur in der DTD verwendet werden. Im Dokument selbst hat das Prozentzeichen keine spezielle Bedeutung, die Referenz auf das Parameter-Entity wird also nicht erkannt.

Ersetzung von Entities

• Der Inhalt eines ``parsed'' Entities heißt auch sein Ersetzungstext.
• Das gleiche Entity kann mehrfach definiert werden, die erste Definition ist dann ausschlaggebend, alle anderen werden ignoriert. Ein XML-Parser kann als Option anbieten, bei mehrfacher Deklaration von Entities eine Warnung auszugeben.
• Der Ersetzungstext eines ``general parsed'' Entities muß syntaktisch zwischen einem öffnenden und einem schließenden Tag möglich sein Das bedeutet, daß es nicht möglich ist, daß ein Tag, Kommentar, etc. in einem Entity beginnt, und in einem anderen Entity endet. Physische und logische Struktur sind dann also immer korrekt geschachtelt. Dies ist zum Beispiel wichtig, wenn die externen Entities nicht gelesen wurden, so daß ihr Ersetzungstext nicht bekannt ist. Die Wohlgeformtheit des Hauptdokumentes kann dennoch geprüft werden. Die Programmierung von Parsern wird auch einfacher, wenn nach der Verarbeitung eines Entities zum Beispiel keine öffnenden spitzen Klammern übrig sein können.
• Entities können auch in der Definition von anderen Entities verwendet werden, z.B.:

  <!ENTITY a "xxx">

  <!ENTITY b "yyy &a; zzz">

  Wenn die Definition verarbeitet wird, wird zunächst einfach der gegebene Text mit Referenzen anderer ``general'' Entities als Ersetzungstext abgespeichert. Daher könnten die beiden Deklarationen auch in der umgekehrten reihenfolge angegeben sein: Man würde keine Fehlermeldung bekommen, daß ``a'' nocht nicht definiert ist. Erst wenn ``&b;'' im eigentlichen Text des Dokumentes auftaucht, wird zu seinem Ersetzungstext expandiert. Diese Ersetzung geschieht dann rekursiv: Da das Dokument nun &a; enthält, wird auch die Definition für a eingesetzt. Im Ende erhält man also ``yyy xxx zzz''.
• Der Ersetzungstext der vordefinierten Entities, zum Beispiel amp, zählt aber immer als Daten, und führt nicht rekursiv zur Erzeugung neuer Entity-Referenzen. Zum Beispiel wird in ``AT&T;'' nicht nach der ersten Ersetzung noch eine Ersetzung für ``&T;'' versucht. Dies folgt der generellen Linie in XML, daß die Ersetzung von Entities nicht zur Erzeugung von neuen Strukturen führt. Zum Beispiel kann man nicht ein Tag aus mehreren Entities zusammensetzen. So kann man auch nicht durch den Ersetzungsmechanismus eine vorher nicht existierende Entity-Referenz bekommen. Entsprechend werden Anführungszeichen, die durch eine Entity_Referenz in einen Attributwert hineinkommen, der mit den gleichen Anführungszeichen begrenzt ist, nicht als Begrenzer aufgefaßt.
• Allerdings werden Zeichen-Referenzen schon ersetzt, wenn die Entity-Definition verarbeitet wird (nicht rekursiv). Z.B. kann man amp; nur so selbst definieren:

  <!ENTITY amp "&#38;#38;">

  Wenn die Definition verarbeitet wird, wird & zu ``&'' ersetzt. Der Ersetzungstext ist dann also (wie gewünscht) ``&''. Wenn & im Text verwendet wird, wird es zu ``&'' expandiert, und dies dann durch das Zeichen & ersetzt, das nun aber keine spezielle Bedeutung mehr hat.
• Entities müssen deklariert werden, bevor auf sie mit Entity-Referenzen zugegriffen werden kann (dagegen kann es bei Element-Typen Vorwärts-Referenzen geben). Weil die Entity-Referenzen f"ur General Entities erst bei der sp"ateren Verwendung im Text ausgewertet werden, ist das f"ur sie kein Problem. Nur bei der Definition des Default-Wertes eines Attributes werden General Entities ausgewertet, w"ahrend die DTD gelesen wird. Hier mu\3 die Definition der Verwendung textuell vorausgehen. Parameter Entities werden sofort ausgewertet, wenn sie in der DTD aufgerufen werden. Hier mu\3 die Definition immer textuell vor der ersten Verwendung stehen.
• Nat"urlich kann sich kein Entity direkt oder indirekt selbst aufrufen. Das folgende Beispiel w"are unzul"assig:

  <!ENTITY a "xxx &b; xxx">

  <!ENTITY b "yyy &a; yyy">

  Bei schlechten Parsern k"onnte dies zu einer Endlos-Rekursion f"uhren.
• Im Abschnitt~4.4 der XML Spezifikation findet sich eine Tabelle, was mit Referenzen auf die verschiedenen Arten von Entities in verschiedenen Kontexten geschieht.

External Entities

• Mit externen parsed Entities kann man den Text aus einer Datei in das Dokument einf"ugen. Dies ist besonders f"ur gro\3e Dokumente n"utzlich, zum Beispiel kann man jedes Kapitel in eine eigene Datei schreiben. Es erlaubt auch einen modulareren Aufbau, so kann man etwa die DTD aus mehreren Modulen in unterschiedlichen Dateien zusammensetzen.
• Externe Entities gibt es als General Entities (f"ur Text) und als Parameter Entities (f"ur DTDs). Externe General Entities werden folgenderma\3en deklariert:

  <!ENTITY lic SYSTEM "license.xml">

  Der Inhalt der Datei ``license.xml'' kann dann mit ``&lic;'' eingef"ugt werden (es ist also eine normale Entity-Referenz). Will man eine Datei in die DTD einbinden, so geschieht das folgenderma\3en:

  <!ENTITY % tables SYSTEM "tab.xml">

  %tables;

Unparsed Entities

• Unparsed Entities sind Dateien, die nicht im XML Format vorliegen, aber zum Dokument geh"oren. Ein Beispiel w"aren etwa Bilder im GIF Format.
• In solchen F"allen mu\3 man zuerst einen Namen f"ur das Format definieren. Das geschieht mit einer Notations-Deklaration:

  GIF SYSTEM "gifmagic.exe"

  POSTSCRIPT PUBLIC "+//ISBN 0-201-18127-4::Adobe//NOTATION Postscript Language Ref. Manual//EN"

  Die Angabe nach SYSTEM k"onnte z.B.~ein Programm sein, da\3 dieses Format anzeigen kann, aber das ist keine Bedingung. Auch eine Quelle f"ur weitere Informationen "uber das Format (wie das Postscript Referenz Handbuch) kann zur Identifizierung dienen.
• Anschlie\3end kann man ein Entity dieses Formates deklarieren:

  <!ENTITY clown SYSTEM "clown.gif" NDATA GIF>

  Durch den Zusatz ``NDATA'' mit der Format-Angabe ist klar, da\3 es sich hier um ein unparsed Entity handelt.
• Man kann unparsed Entities nicht direkt referenzieren, aber man kann Attribute deklarieren, die Entities bestimmter Formate akzeptieren:

  <!ELEMENT IMG EMPTY>

  <!ATTLIST IMG SRC ENTITY #REQUIRED>

• Im Text kann man dann schreiben

  <IMG SRC="clown"/>

Original URL: http://www.informatik.uni-giessen.de/staff/brass/xml00/xmlnotes.xml/