Glossar |
Haupttext XML-Syntax Fragen und Antworten |
[general entity; Gegenstück: Parameter-Entity]
Der Verfasser von DTDs hat die Möglichkeit, Kürzel zu definieren.
Dies ist ein Beispiel für die Deklaration eines Kürzels:
<!ENTITY mwm "Motorenwerke Mannheim" > |
Man unterscheidet zwischen allgemeinen Entities und Parameter-Entities.
Parameter-Entities werden nur innerhalb von Dokumenttyp-Definitionen verwendet.
Soll heißen: Die Ersetzung, die beim Parsen vorgenommen wird, betrifft
nur die DTD. Der Ersetzungstext von allgemeinen Entities dagegen erscheint
im Dokument selbst.
Bei der Deklaration von Attributen wird jedes Attribut einem Typ zugeordnet.
Es gibt drei Hauptgruppen von XML-Attribut-Typen:
<!ATTLIST termdef id ID #REQUIRED name CDATA #IMPLIED> <!ATTLIST list type (bullets|ordered|glossary) "ordered"> <!ATTLIST form method CDATA #FIXED "POST"> |
Hier werden zu den Elementen termdef, list und form Attribute definiert. Jedes Attribut wird einem Attribut-Typ zugeordnet (name wird zum Beispiel dem Typ CDATA zugeordnet.) |
In Attribut-Deklarationen wird festgelegt, ob das Attribut immer erscheinen muß, wenn das entsprechende Element in das Dokument gesetzt wird. XML bietet dafür diese Schlüsselwörter:
<!ATTLIST termdef id ID #REQUIRED name CDATA #IMPLIED> <!ATTLIST list type (bullets|ordered|glossary) "ordered"> <!ATTLIST form method CDATA #FIXED "POST"> |
Das Attribut 'id' wird dem Attribut-Typ 'ID' zugeordnet.
Die Attribute 'name' und 'method werden dem Attribut-Typ 'CDATA' zugeteilt. Das Attribut 'type' wird dem Aufzählungstyp zugeordnet. |
Einige Anmerkungen zu den Attributen, die unter dem Oberbegriff 'Token-Typ' zusammengefaßt werden:
Bei der Deklaration von Attributen wird jedes Attribut einem Typ zugeordnet.
Es gibt drei Hauptgruppen von XML-Attribut-Typen:
<!ATTLIST list type (bullets|ordered|glossary) "ordered"> |
Für das Element list wird hier das Attribut type deklariert. Es wird festgelegt, daß 'type' immer einen der drei vorgegebenen Werte annehmen muß. Wenn das Element list ohne das type-Attribut im Dokument erscheint, soll es automatisch den Wert ordered zugewiesen bekommen. |
Wenn Sie ein Dokument auf eine externe DTD ausrichten, dann können Sie festlegen, daß bestimmte Abschnitte der DTD eingelesen werden, andere dagegen nicht.
Voraussetzung ist allerdings, daß der Verfasser der DTD entsprechende Vorkehrungen getroffen hat. Konkret: Der Verfasser der DTD muß in die DTD sogenannte bedingte Abschnitte gesetzt haben.
XML stellt für bedingte Abschnitte die Schlüsselwörter
INCLUDE und IGNORE zur Verfügung.
Wenn ein Abschnitt mit INCLUDE eingeleitet wird, bedeutet das, daß
der Abschnitt berücksichtigt werden soll, wenn der Abschnitt mit IGNORE
eingeleitet wird, bedeutet das, daß er übergangen werden soll.
<![INCLUDE[
<!ELEMENT buch (titel, rumpf, anhaenge?)> ]]> |
Die Deklaration für den Elementtyp buch befindet sich hier in einem bedingten Abschnitt, der mit INCLUDE eingeleitet wird und wird deswegen beim Einlesen der DTD berücksichtigt. |
<!ENTITY % entwurf 'INCLUDE' > <!ENTITY % fertig 'IGNORE' > <![%entwurf;[ <!ELEMENT buch (kommentare*, titel, rumpf, anhaenge?)> ]]> <![%fertig;[ <!ELEMENT buch (titel, rumpf, anhaenge?)> ]]> |
Es gibt in XML-Dokumente drei Arten von Markup: Struktur-Markup (Tags für Überschriften, Tabellen, Listen und anderes), Formatierungs-Markup (Tags für Fettdruck, Kursivschrift und anderes) und beschreibenden Markup (wie zum Beispiel die Tags in <autor> Joseph Roth </autor>).
Die Tags die für beschreibendes Markup verwendet werden, werden
häufig als semantische Tags bezeichnet.
Beispiel für die Deklaration:
<!ATTLIST produkt name CDATA #REQUIRED> |
Für das Element produkt wird hier das Attribut name deklariert. Das Attribut soll vom Typ CDATA sein, und es wird festgelegt, daß es immer angegeben werden muß, wenn das Element produkt im Dokument erscheint. |
CDATA-Abschnitte sind Teile von XML-Dokumenten, die nicht geparst werden. Wenn in einem CDATA-Abschnitt also Markup erscheint, wird es vom Parser nicht berücksichtigt.
Beispiel:
<![CDATA[<gruss>Hallo Welt!</gruss>]]> |
Die Zeichenfolgen <gruss> und </gruss> erscheinen hier in einem CDATA-Abschnitt. Der Parser wird sie daher nicht als Markup ansehen. |
Den Effekt, den man im obigen Beispiel durch einen CDATA-Abschnitt erreicht, kann man auch erreichen, indem man die Sonderzeichen ersetzt. Das sieht dann im Quelltext des XML-Dokuments so aus:
<tag>Hello, world!</tag>
Die CDATA-Technik zu verwenden wird in den meisten Fällen für
den Web-Autor die bequemere Möglichkeit sein, denn es lassen sich
XML-Daten aus anderen Dokumenten herausnehmen und können direkt in
den CDATA-Abschnitt übernommen werden - ohne daß jedes Sonderzeichen
(<,& usw.) durch ein anderes Zeichen ersetzt werden muß.
Dokumenttyp-Definitionen (DTDs) enthalten in erster Linie Deklarationen. Man unterscheidet folgende Arten von Deklarationen:
Dokumenttyp-Deklaration, Elementtyp-Deklaration, Attribut-Deklaration
(=Attributlisten-Deklaration), Entity-Deklaration, Text-Deklaration, Notation-Deklaration.
Ein Beispiel-Dokument:
<?xml version="1.0"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede>Hallo Leute!</anrede> <text>Alles paletti.</text> </brief> |
Das <brief>-Element bildet hier das Wurzelelement. In der Dokumenttyp-Deklaration in Zeile 2 erscheint daher der Name brief. |
Für den Verfasser von XML-Dokumenten macht sich die Verwendung von DTDs in erster Linie als Einschränkung bemerkbar. Es können nur bestimmte Elemente verwendet werden, und es müssen die Vorgaben für die Verschachtelung der Elemente und für die Attribut-Werte eingehalten werden.
Die Disziplin, die sich der Dokument-Verfasser auferlegt, bringt jedoch Vorteile mit sich: Dadurch, daß alle Dokumente gleichen Regeln folgen, ist es möglich, Anwendungen einzusetzen, die die Informationen aus den Dokumenten auslesen und automatisch verarbeiten.
Wenn alle Dokumente eine größere Zahl von Dokumenten auf dieselbe DTD ausgerichtet wurden, dann ist es außerdem möglich, auf alle diese Dokumente dieselben Formatierungs-Richtlinien anzuwenden. Wer ein XML-Dokument verfaßt, muß sich häufig um die Formatierung keine Gedanken machen, da eine Dokument-übergreifenden Formatierungs-Vorlage zum Einsatz kommt.
Eine Dokumenttyp-Definition kann in einer separaten Datei untergebracht
werden; man spricht dann von einer externen DTD (oder auch von einer externen
DTD-Untermenge). Die Definitionen können aber auch an den Anfang von
einem Dokument erscheinen. In diesem Fall spricht man von einer internen
DTD (bzw. einer internen DTD-Untermenge).
Beispiel:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE gruss SYSTEM "hello.dtd"> <gruss> Hallo XML!</gruss> |
Die Dokumenttyp-Deklaration in Zeile 2 gibt an, daß das Dokument auf die DTD hello.dtd ausgerichtet wurde. |
<?XML version="1.0" standalone="no"?>
<!DOCTYPE chapter SYSTEM "dbook.dtd" [ <!ELEMENT ulink (#PCDATA)*> <!ATTLIST ulink xml-link CDATA #FIXED "SIMPLE" xml-attributes CDATA #FIXED "HREF URL" URL CDATA #REQUIRED ]> <chapter> ... </chapter> |
In diesem Dokument verweist die Dokumenttyp-Deklaration auf die DTD dbook.dtd. Das Dokument enthält außerdem in eckigen Klammern ( [ und ] ) als Bestandteil der Dokumenttyp-Deklaration eine internen DTD-Untermenge. Die Untermenge besteht aus einer Elementtyp-Deklaration und einer Attributlisten-Deklarationen. |
Es gilt die Konvention, daß der Name des öffnenden Tags (des
Root-Tags) der Name des Dokuments ist (im Beispiel: 'chapter').
Beispiel für ein Element:
<autor>Joseph Roth</autor> |
<ELEMENT autor #PCDATA> |
<p>XML <em>bedeutet nichts.</em>XML ist einfach nur Syntax. Syntax jedoch kann <em> sehr </em> nützlich sein. </p> |
Bei Möglichkeit (3) spricht man von Gemischtem Inhalt.
Ein Beispiel für ein Element mit Gemischtem Inhalt ist das <P>-Element
von HTML. Dieses Element kann normalen Text enthalten, der mit allen möglichen
Arten von anderen Elementen durchmischt sein kann, zum Beispiel A, B, I
und IMG in jeder beliebigen Abfolge.
Für Elemente mit gemischtem Inhalt gilt die Besonderheit, daß
zwar festgelegt werden kann, welche Elemente als untergeordnete Elemente
auftreten können, es kann aber nicht festgelegt werden, in welcher
Reihenfolge die Elemente auftreten und wieviele es höchstens sein
können.
<!ELEMENT br EMPTY> <!ELEMENT p (#PCDATA|emph)* > <!ELEMENT %name.para; %content.para; > <!ELEMENT container ANY> |
Die Inhaltsmodelle folgen dieser Syntax:
EMPTY zeigt an, daß das Element keinen Inhalt hat.
ANY zeigt an, daß jede Art von
Inhalt erlaubt ist.
Gemeinsam ist allen Entities, daß es für sie einen Namen gibt und daß sie einen Inhalt haben. Die zugrundeliegende Idee sieht so aus: Es muß möglich sein, im Dokument den Namen des Entity anzuführen und dadurch den Parser dazu zu bringen, daß er den Inhalt des Entity in das Dokument (oder in die DTD) einfügt.
Die meisten Entities müssen in einer Deklaration einen Namen zugewiesen bekommen, bevor auf sie in einem Dokument verwiesen werden kann. Wenn ein Entity deklariert wurde, kann der Entity-Name als ein Kürzel verwendet werden, und der Parser wird dafür sorgen, daß an die Stelle des Entity der Ersetzungstext gesetzt wird.
Für Entities gibt es drei Einteilungskriterien: Man unterscheidet geparste von nicht-geparsten Entities. Außerdem teilt man in allgemeine und in Parameter-Entities ein, und zuletzt gibt es noch die Unterscheidung zwischen internen und externen Entities.
(1) geparste versus nicht-geparste Entities
Nicht-geparste (genauer: nicht zu parsende) Entities sind solche, in
denen der Parser nicht nach Markup suchen muß (zum Beispiel Sounddateien,
die in ein Dokument eingebunden werden). Zu jeder nicht-geparsten Entity
gehört eine sogenannte Notation-Deklaration.
Geparste Entities sind entsprechend solche, die geparst werden.
(2) allgemeine versus Parameter-Entities
Parameter-Entities haben die Besonderheit, daß das zugehörige Kürzel nur in eine DTD gesetzt werden kann und daß der Ersetzungstext daher in jedem Fall einen Bestandteil der DTD bilden wird.
Alle übrigen Entities (also jene, deren Ersetzungstext nicht in die DTD, sondern in das Dokument eingefügt wird) sind allgemeine Entities.
Beispiel für die Deklaration eines allgemeinen Entity:
<!ENTITY mwm "Motorenwerke Mannheim" >
|
<!ENTITY % mwm "Motorenwerke Mannheim" > |
Einen Unterschied gibt es auch beim Aufruf der Entities im Dokument:
Der Aufruf des allgemeinen Entity würde so aussehen: &mwm;
Der Aufruf de Parameter-Entity würde so aussehen: %mwm;
(3) interne versus externe Entities
Als interne werden alle Entities bezeichnet, deren Ersetzungstext durch die Entity-Deklaration geliefert wird. Bei den oben angeführten Deklarationen für eine allgemeine und für eine Paramter-Entity handelt es sich um interne Entities; der Ersetzungstext ("Mannheimer Motorenwerke") wird in der Deklaration angeführt.
Hier ein Beispiel für die Deklaration eines externen Entity:
<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml"> |
Interne Entities können Referenzen auf andere interne Entities enthalten, man kann sie allerdings nicht rekursiv verwenden. (Ein Entity kann nicht sich selbst aufrufen.)
Beispiel für die Verwendung einer Entity-Referenz innerhalb einer
Entity-Deklaration:
<!ENTITY AC "Das &W3C; Advisory Council">
<!ENTITY W3C "WWW Consortium"> |
Und noch ein Hinweis: Start-Tags, End-Tags, Leeres-Element-Tags, Elemente,
Kommentare, Processing Instructions, Zeichen- oder Entityreferenzen können
nicht in einem Entity beginnen und in einem anderen enden.
Dies ist ein Beispiel für die Deklaration eines allgemeinen Entity:
<!ENTITY mwm "Motorenwerke Mannheim" >
|
<!ENTITY % mwm "Motorenwerke Mannheim" >
|
<!ENTITY ATIlogo SYSTEM "/standard/logo.gif" NDATA
GIF87A>
|
Hier wird ein externes nicht-geparstes Entity deklariert. Das Schlüsselwort NDATA gibt für den Parser den Hinweis, daß in der Datei nicht nach Markup gesucht werden muß. |
Wenn ein Entity im Dokument verwendet werden soll, muß man sie einfach nur mit ihrem Namen ansprechen. Parameter-Entity-Referenzen beginnen mit dem Prozentzeichen (%) und enden mit einem Semikolon (;). Entity-Referenzen beginnen mit dem 'Kaufmanns-Und' (&) und enden ebenfalls mit einem Semikolon.
Es gibt eine spezielle Form von Entity-Referenz, die Zeichen-Referenz
genannt wird und dazu dient, beliebige Unicode-Zeichen in einen Text einzufügen.
Man verwendet Zeichen-Referenzen, um Zeichen einzufügen, die nicht
direkt eingetippt werden können.
Es könnte sich sogar herausstellen, daß sich nur die DTDs,
die vom W3C abgesegnet werden, als tragfähig erweisen. In dem Fall
wären für die Erweiterung dieselben Gremien zuständig, die
sich früher um die Erweiterung von HTML gekümmert haben.
<!ENTITY Pub-Status "Dies ist Version 1.1 dieses Dokuments"> |
<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml">
|
Im vorherigen Beispiel wurde ein geparstes externes Entity deklariert.
Dies ist die Deklaration für ein nicht-geparstes externes Entity:
<!ENTITY Xlogo SYSTEM "/standard/logo.gif" NDATA
GIF87A>
|
Die Entity-Referenz &Xlogo; kann nur als Wert eines Attributs auftreten.
Dazu ein Beispiel: Wenn ein Element brief deklariert wurde, dann kann
es für das Element diese Attributlisten-Deklaration geben:
<!ATTLIST brief logo ENTITY >
|
<brief logo='Xlogo'>
|
Externe nicht-geparste Entities sind nötig, damit auf Bilder und
auf andere Nicht-XML-Inhalte verwiesen werden kann.
Die Deklarationen, die in einer Dokumenttyp-Definition gegeben werden,
können sich in einer externen Datei befinden, können aber auch
im XML-Dokument erscheinen. (Auch die Möglichkeiten "nur Deklarationen
in externer Datei" und "nur Deklarationen innerhalb vom Dokument" sind
gegeben). Der Parser wird immer alle diese Deklarationen zusammenfassen
und als eine gesamte Dokumenttyp-Definition behandeln.
Der Inhalt eines Elements - das ist all das, was zwischen dem Start-Tag und dem End-Tag eines Elements erscheint. Man unterscheidet drei verschiedene Arten von Inhalt:
Dies ist ein Beispiel für die Deklaration eines Element-Typs mit
gemischtem Inhalt:
<!ELEMENT z (#PCDATA|a|ul|b|i|em)*> |
Diese Element-Typ-Deklaration legt fest, daß in z-Elementen normaler Text und die Elemente a, ul, b, i, em abwechselnd auftreten können. |
Die Unterscheidung zwischen den drei Arten von Inhalten von Elementen ist wichtig, weil es bei gemischtem Inhalt eine Besonderheit gibt: Bei der Deklaration von Elementen mit gemischtem Inhalt können die Typen der Kindelemente beschränkt werden, nicht jedoch ihre Reihenfolge oder die Anzahl der insgesamt enthaltenen Elemente.
Man kann sich dies anhand von dem <DL>-Element und dem <P>-Element von HTML klar machen:
Das <DL>-Element kann nur <DT>- und <DD>-Elemente enthalten.
Der Inhalt eines <DL>-Elements ist somit ein Beispiel für ein Element,
das ausschließlich Elemente als Inhalt enthält.
Das <P>-Element dagegen kann normalen Text enthalten, der mit allen
möglichen Arten von anderen Elementen durchmischt sein kann, zum Beispiel
A, B, I und IMG in jeder beliebigen Abfolge.
Der Regelung, daß bei gemischtem Inhalt nicht bestimmt werden
kann, in welcher Ordnung die in den Text eingestreuten Kind-Elemente erscheinen,
liegen viele Jahre mit Erfahrung mit SGML zugrunde. (In SGML kann die Abfolge
festgelegt werden, es wird allerdings davon abgeraten, von dieser Möglichkeit
Gebrauch zu machen).
Geparste Entities sind im Bereich der Entities der Normalfall. Der Prozessor sorgt beim Aufbereiten eines Dokuments dafür, daß an die Stelle einer Entity-Referenz ihr Ersetzungstext tritt, und der Ersetzungstext wird zu einem Bestandteil des Dokuments bzw. der DTD. Da der Parser im Ersetzungstext nach Markup suchen wird, spricht man von geparsten Entities (bzw. von zu parsenden Entities).
Deklarationen für nicht-geparste Entities haben diese Form:
<!ENTITY logo SYSTEM "/standard/logo.gif" NDATA
GIF87A>
|
Als Konsequenz daraus ergibt sich, daß es keine Flexibilität
bei der Schreibung der Schlüsselwörter gibt. Sie müssen
immer in Großbuchstaben erscheinen. Man muß also <!DOCTYPE
und <!ELEMENT und <!ATTLIST und <!NOTATION schreiben. Dasselbe
gilt für Schlüsselwörter wie SYSTEM und PUBLIC, und für
die Schlüsselwörter, die in Attribut-Deklarationen auftreten
(ID, CDATA, NMTOKEN und andere) .
Ein XML-Dokument ist gültig, wenn es auf eine Dokumenttyp-Definition
(DTD) ausgerichtet wurde. Auf die DTD muß in einer Dokumenttyp-Deklaration
am Anfang des Dokuments (hinter der optionalen XML-Deklaration) verwiesen
werden, und das Dokument muß die Festlegungen der DTD einhalten.
Die DTD zu schreiben, war jeweils allenfalls die halbe Arbeit. Es mußten zusätzlich HTML-Spezifikationen verfaßt werden, in denen für alle vorgesehenen Tags festgelegt wurde, wie sich Browser zu verhalten haben, wenn sie die Tags zu verarbeiten haben.
Es wird daran gearbeitet, HTML auf die Grundlage von XML zu stellen.
HTML wird dann eine Auszeichnungssprache sein, die neben anderen im Web
zum Einsatz kommt. Die aktuelle Planung beim W3C sieht vor, daß
HTML in mehrere auf XML basierende Module untergliedert wird.
Das neue HTML wird abwärtskompatibel sein. (Browser, die auf das
neue HTML ausgerichtet sind, werden alte HTML-Dateien verarbeiten können,
die alten Browser werden aber mit den neuen HTML-Dokumenten nicht umgehen
können.)
<!ATTLIST termdef id ID #REQUIRED> |
Hier wird für das Element termdef ein Attribut deklariert, das den Namen id hat und vom Typ ID ist. Mit #REQUIRED wird festgelegt, daß das id-Attribut immer angegeben werden muß, wenn das <termdef>-Element im Dokument erscheint. |
ID-Attribute sind allerdings auch unabhängig von IDREF-Attributen von Bedeutung, denn sie geben Elementen unverwechselbare Adressen. In der Zukunft werden sie eine wichtige Rolle spielen, da sie die Ziele (targets) für Links bilden, die von außen auf das Dokument verweisen.
Der Wert eines IDREF-Attributs muß sich auf ein einzelnes ID-Attribut
eines Elements des Dokuments beziehen. Der Wert eines IDREFS-Attributs
kann demgegenüber mehrere IDREF-Werte umfassen, die durch eine Leerstelle
getrennt werden.
<!ELEMENT spec (front, body, back?)> <!ELEMENT div1 (head, (p | list | note)*, div2*)> <!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*> |
Die Inhaltsmodelle folgen dieser Syntax:
EMPTY zeigt an, daß das Element keinen Inhalt hat (und somit auch keinen End-Tag).
ANY zeigt an, daß jede Art von Inhalt erlaubt ist.
Als internes Entity wird jedes Entity bezeichnet, dessen Wert in der
Entity-Deklaration geliefert wird. Dies ist ein Beispiel für die Deklaration
eines internen Entity:
<!ENTITY Pub-Status "Dies ist Version 1.1 dieses Dokuments"> |
Hier wird das Entity Pub-Status (kurz für: Publikations-Status) deklariert. Der Wert des Entity, der hier angegeben wird, bildet den Ersetzungstext des Kürzels. Das zu dem Entity gehörige Kürzel wird so aussehen: &Pub-Status; |
<!ENTITY boilerplate SYSTEM "/standard/legalnotice.xml">
|
Hier wird das Entity boilerplate deklariert. Wenn anschließend im Dokument das Kürzel &boilerplate; erscheint, wird der Parser das Kürzel durch den Inhalt der Datei legalnotice.xml ersetzen. |
Die Deklarationen, die in einer Dokumenttyp-Definition gegeben werden,
können sich in einer externen Datei befinden, können aber auch
in das XML-Dokument gesetzt werden. (Auch die Möglichkeiten "nur Deklarationen
in externer Datei" und "nur Deklarationen innerhalb vom Dokument" sind
gegeben). Der Parser wird immer alle diese Deklarationen zusammenfassen
und als eine gesamte Dokumenttyp-Definition behandeln.
Es gilt die Regel, daß die zuerst eingelesenen Deklarationen
gegenüber den nachfolgenden Deklarationen Vorrang haben. Da immer
zuerst die interne Untermenge eingelesen wird, kann man die interne DTD
dazu nutzen, die Angaben in der externen Untermenge zu überschreiben.
Dies ist ein Beispiel für ein Dokument mit einer internen Untermenge:
<?xml version="1.0"? encoding="UTF-8">
<!DOCTYPE gruss [ <!ELEMENT gruss (#PCDATA)> ]> <gruss> Hallo XML!</gruss> |
In der zweiten Zeile beginnt die Dokumenttyp-Deklaration. Die Dokumenttyp-Deklaration enthält in eckigen Klammern ( [und ] ) eine DTD-Untermenge. In diesem Fall besteht die interne Untermenge aus einer einzelnen Elementtyp-Deklaration. |
Eine Kodierungs-Deklaration zeigt an, welche Zeichenkodierung verwendet
wird.
Dies ist ein Beispiel für eine XML-Deklaration, die eine Kodierungsdeklaration
enthält:
<?xml version="1.0" encoding='EUC-JP'?> |
Hier wird innerhalb einer XML-Deklaration eine Versions-Deklaration und eine Kodierungs-Deklaration gegeben. |
<!--Dies ist ein Kommentar.--> |
Die Zeichenkette »--« (zwei Trennstriche) darf in einem
Kommentar nicht erscheinen.
Beispiel für die Deklaration eines leeren Elements in der DTD:
<!ELEMENT br EMPTY> |
Unter dem Oberbegriff Leerraum werden Leerzeichen, Tabulator-Zeichen, Zeilenende-Markierungen und Leerzeilen zusammengefaßt.
Es gilt die Regel, daß Leerraum bewahrt werden muß. Auch wenn es sich um Leerraum handelt, der lediglich in den Quellcode des XML-Dokuments eingefügt wurde, damit ein menschlicher Betrachter sich besser darin orientieren kann, wird dieser Leerraum an die Anwendung weitergegeben.
Es gibt ein Standard-Attribut, mit dem besonders darauf hingewiesen
werden kann, daß der Leerraum erhalten bleiben soll. Wenn dieses
Attribut in einer Deklaration einem Element zugeordnet wird, sieht
das so aus:
<!ATTLIST gedicht xml:space (default|preserve) 'preserve'> |
<gedicht xml:space="preserve"> |
Es gibt zwei unterschiedliche Arten, die Struktur eines Dokuments zu beschreiben. Zum einen hat ein Dokument eine logische Struktur. Wer die logische Struktur eines Dokuments betrachtet, sieht hierarchisch angeordnete Informationen, wobei die Informationseinheiten durch Elemente gebildet werden. Da die Elemente ineinander verschachtelt sind, ist es möglich, ihre Abhängigkeit voneinander in einer Baumstruktur darzustellen. Die Spitze des Baumes wird dabei durch das sogenannte Dokument-Element gebildet.
Wenn man demgegenüber die physische Struktur eines Dokuments beschreibt,
stellt man dar, aus welchen Entities sich das Dokument zusammensetzt.
Als Markup werden alle Zeichen betrachtet, die nicht für den menschlichen Betrachter in den Text gesetzt werden, sondern für die Auswertung durch Programme vorgesehen sind.
In XML gibt es diese Arten von Markup:
Start-Tags, End-Tags, Tags von leeren Elementen, Entity-Referenzen,
Zeichen-Referenzen, Kommentare, Begrenzungen für CDATA-Abschnitte,
Dokumenttyp-Deklarationen, Processing Instructions.
Markup-Deklarationen können den Inhalt eines Dokumentes beeinflussen,
so daß er verändert vom Parser an die Anwendung weitergereicht
wird. Beispiele sind Vorgaben für Attributwerte sowie Entity-Deklarationen.
Für XML sind die Mime-Tpen text/xml und application/xml vorgesehen.
Gültige Definitionen für diese Mime-Typen stehen noch aus.
Der Doppelpunkt (:) wird für experimentelle Zwecke reserviert. Man darf den Doppelpunkt verwenden, sollte das aber nicht tun, da er später möglicherweise noch eine spezielle Bedeutung zugeteilt bekommen wird.
XML beachtet Groß- und Kleinschreibung. Die Namen <Ein_Tag> <ein_Tag> und <EIN_TAG> wird der Parser daher klar unterscheiden.
Namen können nicht-lateinische (zum Beispiel hebräische oder
koreanische) Zeichen enthalten.
Aber sie können nicht mit den drei Buchstaben "X", "M" und "L"
beginnen.
Dies sind Beispiele für zulässige Namen:
Tim
société
w3-c:Parsed_Entity
Die folgenden Namen sind nicht zulässig:
xmlu
2pac
P=NP
Wenn über Namensraum-Probleme diskutiert wird, dann kommt immer
wieder die Verwendung von Doppelpunkten ( : ) als Lösungsmöglichkeit
ins Spiel. Das Problem mit der Doppeldeutigkeit von 'Schloß' würde
man lösen, indem man zwischen <Gebäude:Schloß> und <Schließvorrichtung:Schloß>
unterscheidet.
<!ENTITY bild SYSTEM "../bilder/OpenHatch.gif" NDATA gif > |
Hier wird das Entity bild deklariert. Es wird eine Adresse angegeben, unter der das Entity zu finden ist. Wenn bestimmt werden soll, wie mit dem Entity zu verfahren ist, muß nach der Deklaration für die Notation gif gesucht werden. |
Hinter das Schlüsselwort wird der Name einer Notation gesetzt.
Eine Notation ist eine besondere Art von Deklaration. (Die Ausdrücke
Notation und Notation-Deklaration bedeuten letztlich Ähnliches.) In
einer Notation-Deklaration wird ein Name mit einem sogenannten Public Identifier
verbunden, und wenn die Sache gut läuft, dann sagt der Public Identifier
etwas darüber, wie mit dem externen Entity zu verfahren ist
- etwa indem der Public Identifier auf eine Anwendung verweist, an die
das externe Entity übergeben werden kann.
Beim Parsen wird im allgemeinen der Ersetzungstext einer Entity-Referenz in das Dokument bzw. in die DTD übernommen. Einen Sonderfall bilden Referenzen auf binäre Entities.
Dies ist ein Beispiel für die Deklaration eines nicht-geparsten
Entity:
<!ENTITY logo SYSTEM "/standard/logo.gif" NDATA
GIF87A>
|
Geparste Entities werden durch Entity-Referenzen aufgerufen. Nicht-geparste
Entities haben dagegen die Besonderheit, daß ihr Name nur als Attribut-Wert
auftreten kann - und zwar als Wert von Attributen des Typs ENTITY oder
ENTITIES.
Ein Parser, der imstande ist, Dokumente auf Gültigkeit zu prüfen, wird als validierender Parser bezeichnet.
Nicht-validierende Parser führen keinen Abgleich zwischen dem Dokument
und einer DTD durch - auch dann, wenn es im Dokument eine Dokumenttyp-Deklaration
gibt, die auf eine DTD verweist.
Sie überprüfen ausschließlich, ob alle Wohlgeformtheitsbeschränkungen
eingehalten wurden.
Der nicht-validierende Prozessor muß außerdem lediglich
den Inhalt des Dokument-Elements einlesen und muß sich um möglicherweise
enthaltene externe Entitiy-Referenzen nicht kümmern.
<!ATTLIST produkt code NMTOKEN>
|
Unterschied zwischen NMTOKEN und NMTOKENS: Während der Wert eines
NMTOKEN-Attributs nur einen einzelnen Namen als Wert haben kann, kann der
Wert eines NMTOKENS-Attributs mehrere NMTOKEN-Werte umfassen, zwischen
denen ein Leerzeichen das Trennzeichen bildet.
Dies ist ein Beispiel für eine Notation-Deklaration:
<!NOTATION eps SYSTEM "http://www.abc-comp.com/programs/epsview.exe">
|
Hier wird per Deklaration der Name eps mit der Anwendung epsview verbunden. Es wird eine Adresse angegeben, unter der die Anwendung im Netz zu finden ist. |
<!ATTLIST bild typ NOTATION>
|
<bild typ="eps"> ... </bild>
|
Nebenbei: Wenn es einen Start-Tag wie <bild typ="eps"> gibt, dann läßt sich damit nicht ermitteln, wo das Bild zu finden ist. Man kann aber ein zusätzliches Attribut deklarieren (etwa ein Attribut 'source', das dem Attributtyp CDATA zugeteilt wird) und kann diesem Atribut die Adresse als Wert zuteilen.
Die Namen von Notationen werden in unterschiedlichen Zusammenhängen verwendet:
- in Entity-Deklarationen
- in Attributlisten-Deklarationen
- in Processing Instructions
- Verwendung als Attributwerte
<!ATTLIST bild typ NOTATION>
|
<!NOTATION eps SYSTEM "http://www.abc-comp.com/programs/epsview.exe">
|
<bild typ="eps"> ... </bild>
|
Entities werden definiert, damit es für häufig genutzte Texte oder auch für Dateien Kürzel gibt. Sobald solch ein Kürzel definiert wurde, hat jeder Verfasser eines Dokuments die Möglichkeit, das Kürzel zu setzen, und der Prozessor wird dafür sorgen, daß an seiner Stelle der Ersetzungstext erscheint - sofern das Dokument auf die DTD ausrichtet wurde, die die Entity-Deklaration enthält.
Parameter-Entities haben gegenüber allgemeinen Entities die Besonderheit, daß sie nur in DTDs verwendet werden können. Die Deklaration und die Verwendung von Parameter-Entities wird durch dieses Beispiel anschaulich:
In der HTML-DTD wird die folgende Auflistung von Elementtyp-Namen häufig
als Gruppe angesprochen:
H1 | H2 | H3 | H4 | H5 | H6
Dasselbe gilt für diese Abfolge von Elementtyp-Namen:
UL | OL | DIR | MENU
Da die beiden Abfolgen häufig auftreten, liegt es nahe, für
jede der beiden Gruppen von Elementtyp-Namen ein Entity zu deklarieren.
Die Deklarationen sehen so aus:
<!ENTITY % headings "H1|H2|H3|H4|H5|H6">
<!ENTITY % list "UL|OL|DIR|MENU"> |
Hier werden die Parameter-Enties headings und list deklariert. Headings bekommt den Wert "H1|H2|H3|H4|H5|H6" zugewiesen und list den Wert "UL|OL|DIR|MENU". |
Nachdem die Parameter-Entities definiert wurden, kann in der DTD mit
einem Kürzel auf sie verwiesen werden.
Es muß nicht mehr eine lange Auflistung wie diese gegeben werden:
<!ELEMENT BODY (H1|H2|H3|H4|H5|H6|P|UL|OL|DIR|MENU|PRE|HR|IMG)*> |
<!ELEMENT BODY (%headings;|P|%list;|PRE|HR|IMG)*> |
Hier wird das Element BODY deklariert. Im Inhaltsmodell werden die Parameter-Entity-Referenzen %headings; und %list; verwendet. |
Außerhalb der DTD hat das Prozent-Zeichen (%) keine besondere
Bedeutung. Folglich wird das, was in der DTD eine Parameter-Entity-Referenz
wäre, im Inhalt nicht als Markup erkannt.
Die XML-Spezifikation unterscheidet zwischen der physischen Struktur eines Dokuments und der logischen Struktur.
Ein XML-Dokument kann sich aus Bestandteilen von vielen Dateien zusammensetzen. Wenn die logische Struktur eines Dokuments beschrieben wird, dann wird beschrieben, welche Bestandteile beteiligt sind.
Dies ist ein Beispiel für ein XML-Dokument, das sich aus mehreren
Entities zusammensetzt:
<!DOCTYPE handbuch [
<!ENTITY kapitel1 SYSTEM "kap1.xml"> <!ENTITY kapitel2 SYSTEM "kap2.xml"> <!ELEMENT handbuch (kapitel+)> ]> <handbuch> &kapitel1; &kapitel2; </handbuch> |
Hier wird in den eckigen Klammern ([ und ]) eine interne DTD-Untermenge angegeben. In der Untermenge werden die Entities kapitel1 und kapitel2 deklariert, außerdem das Element handbuch. Der Inhalt eines <handbuch>-Elements soll sich aus einem oder mehreren <kapitel>-Elementen zusammensetzen. Das Dokument-Element (= Root-Element) reicht von <handbuch bis </handbuch>. Innerhalb des Dokument-Elements wird auf die Entities kapitel1 und kapitel2 verwiesen. (Da sich ein <handbuch>-Element aus <kapitel>-Elementen zusammensetzen soll, müssen die Teildokumente kapitel1 und kapitel2 ein <kapitel>-Element als Root-Element haben.) |
Die allgemeine Form von PIs sieht so aus:
<?name vadaten?>
Als Name kann der Name einer Anwendung erscheinen. Alle Daten, die auf den Namen folgen, sind optional. Es handelt sich um Daten, um die sich der Parser nicht kümmert. Sie werden einfach an die Anwendung weitergereicht.
Ebenso wie für Kommentare gilt auch für Verarbeitungs-Anweisungen, daß sie nicht Teil des Inhalts des XML-Dokuments sind. Während aber Kommentare im allgemeinen nicht an die Anwendung weitergegeben werden, wird eine PI in jedem Fall weitergegeben.
Als Namen, die in die PIs gesetzt werden, können Namen verwendet
werden, die in Notation-Deklarationen festgelegt wurden.
Dies ist ein kleines Beispiel-Dokument mit einer XML-Deklaration (Zeile
1) und einer Dokumenttyp-Deklaration (Zeile 2):
<?xml version="1.0"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief>Hallo Leute!</brief> |
Es gibt drei Arten von Deklarationen, in denen Web-Adressen angegeben werden:
Manche DTDs sind standadisiert worden und sind in der standardisierten Form die Öffentlichkeit zugreifbar (Beispiele sind die HTML-DTDs). Andere DTDs dagegen haben nur eine lokal begrenzte Bedeutung (DTDs, die nur für eine Web-Site benötigt werden oder nur von bestimmten Institutionen genutzt werden).
Für den ersten Typus von DTDs kann man Public Identifier verwenden.
Public Identifier haben auch schon im Zusammenhang mit HTML eine Rolle
gespielt. Man hatte die Möglichkeit, an den Anfang von jedem Dokument
eine Deklaration wie diese zu setzen.
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 3.2//EN"> |
Public Identifier können nur verwendet werden, wenn es Kataloge gibt, in denen sich zu den jeweiligen Angaben ermitteln läßt, unter welcher Adresse das Dokument oder die DTD zu finden ist.
Für XML gibt es solche Kataloge bisher nicht. Public Identifier haben daher bisher einfach den Status einer guten Idee, die allgemein gutgeheißen wird, aber bisher nicht umgesetzt wurde.
Die Vorteile von Public Identifiern liegen auf der Hand: Wenn es eine DTD bereits auf einem PC (oder in einem Intranet) gibt, dann muß es einen Katalog geben, der auf diese Kopie der DTD verweist, und es wird vermieden, daß die DTD wieder und wieder aus dem Netz geholt wird.
Man kann in XML-Dokumenten Public Identifier verwenden. Bisher ist es jedoch in jedem Fall nötig, daß zusätzlich ein System Identifier angegeben wird, der eine konkrete Adresse nennt . Anders gesagt: Es spricht nichts dagegen, wenn beim Datenaustausch innerhalb einer Firma Public Identifier verwendet werden. Wenn die Dokumente jedoch im Internet angeboten werden, dann muß eine Adresse angegeben werden, die für jeden Internet-Nutzer zugänglich ist, und diese Adresse wird mit einem System Identifier geliefert.
Wenn eine Kombination aus Public Identifier und System Identifier geliefert
wird, erscheint der Public Identifier an der ersten Stelle:
<!ENTITY HTML.Version PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd" > |
RDF soll den Entwicklern eine standardisierte Möglichkeit bieten,
wie sie eine große Menge von Elementen und die Beziehungen, die sie
untereinander haben, notieren können. Daten, die mit RDF erfaßt
wurden, sollen Dokument-übergreifende Suchläufe vereinfachen.
SGML wird dazu genutzt, Tausende von unterschiedlichen DTDs zu definieren.
DTDs gibt es für die unterschiedlichsten Arbeitsgebiete - von der
Übertragung alter sumerischer Schriftrollen bis zu der technischen
Dokumentation eines Stealth-Bombers, von Patientendaten im Krankenhaus
bis zum Aufzeichnen der Noten von Musikstücken.
XML ist eine verkürzte Version von SGML. XML wurde geschaffen,
indem man die komplexeren und weniger genutzten Teile von SGML weggelassen
hat. Von der SGML-Gemeinde wurde der XML-Standard einhellig begrüßt.
Firmen, die sich bisher um SGML-Projekte gekümmert haben, fühlen
sich heute auch für XML zuständig.
<?xml version="1.0" standalone='yes'?> |
Der Wert »no« würde demgegenüber zeigen, daß
möglicherweise externe Markup-Deklarationen vorhanden sind. ('Markup-Deklaration'
ist der Oberbegriff für alle Deklarationen, die in DTDs vorgenommen
werden.)
Man kann allerdings erwarten, daß die Browser auch zukünftig Standard-Vorlagen für die am meisten verbreiteten Elemente bereithalten werden.
Der Einsatz von Cascading Style Sheets (CSS) ist zusammen mit XML problemlos
möglich.
Es wird jedoch an einer Formatierungssprache namens XLS gearbeitet,
die zusätzliche Möglichkeiten bieten wird.
Es gibt drei verschiedene Arten von Deklarationen, in denen Web-Adressen angegeben werden:
Die System Identifier sind bisher die gebräuchlichste Form für
die Angabe von Adressen.
Beispiel für die Verwendung eines System Identifiers bei der Deklaration
eines Parameter-Entity:
<!ENTITY logo SYSTEM "http://www.abc-comp/standard/logo.gif" NDATA GIF87A> |
Dies ist ein Beispiel für eine Text-Deklaration. (Die Zeile kann
in dieser Form den Anfang von einem externen geparsten Entity bilden.)
<?xml version="1.0" encoding="UTF-8"?> |
Diese Text-Deklaration enthält eine Versions-Deklaration und eine Kodierungs-Deklaration. |
Im Rahmen von XML wird zwischen gültigen und wohlgeformten Dokumenten unterschieden. Gültig ist ein Dokument, wenn es auf eine DTD ausgerichtet wurde und die Vorgaben der DTD einhält. Ein Dokument, das nicht auf eine DTD ausgerichtet wurde, kann den Status der Wohlgeformtheit erreichen. Voraussetzung ist, daß das Dokument eine Reihe von Wohlgeformtheitsregeln einhält.
Sowohl validierende als auch nicht-validierende Prozessoren müssen
Verletzungen der Wohlgeformtheitsbeschränkungen, die sie lesen,
melden. Solche Verstöße werden als 'critical errors' betrachtet
und führen dazu, daß der Parser seine Arbeit abbricht.
< steht für die linke
spitze Klammer hervor (<).
> steht für die rechte spitze
Klammer (>).
& steht für das Kaufmanns-Und (&).
' steht für das Hochkomma ( ' ).
" steht für ein Anführungszeichen ( " ).
Wenn diese Entity-Referenzen im Text erscheinen, wird der Parser davon
absehen, die entsprechenden Zeichen als Syntax-Zeichen zu betrachten.
Das W3C ist neben der IETF eine der beiden Organisationen, die Standards
für das Internet entwickeln. Das W3C hat den XML-Standard festgelegt.
(1) Alle Attribut-Werte müssen in Anführungszeichen stehen.
(2) Leere Elemente (das sind Elemente wie <IMG>, <HR>, und <BR>, also solche, die keinen Inhalt und daher auch kein End-Tag haben) müssen entweder mit '/>' enden, oder man muß einen regulären End-Tag hinzufügen. Beispiel: Das aus HTML bekannte <BR> wird entweder zu <BR /> oder zu <BR></BR>. (3) Elemente müssen sauber ineinander eingebettet werden (keine überlappenden Auszeichnungen).
Dies ist ein Beispiel für ein sehr einfaches wohlgeformtes Dokument:
<gruss>Hallo Welt!</gruss> |
Beispiel für ein Dokument mit Wurzelement:
<?xml version="1.0"?> <!DOCTYPE brief SYSTEM "brief.dtd"> <brief> <anrede>Hallo Leute!</anrede> <text>Alles paletti.</text> </brief> |
Dies ist ein Beispiel für eine XML-Deklaration:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> |
Die XML-Deklaration liefert allgemeine Angaben über ein Dokument.
Dieselben Angaben können auch an den Anfang von einem externen geparsten
Entity gesetzt werden. Wenn sie in einer externen geparsten Entity erscheinen,
spricht man allerdings nicht mehr von einer XML-Deklaration, sondern bezeichnet
das Ganze dann als Text-Deklaration.
Jedes XML-Dokument hat sowohl eine »logische« als auch eine
»physische Struktur«.
Physisch besteht das Dokument aus einer Reihe von Einheiten, die als
Entities bezeichnet werden.
Aus logischer Sicht besteht das Dokument aus all den Bestandteilen,
die durch explizites Markup ausgezeichnet sind, also aus Elementen, Entity-Referenzen,
Kommentaren, Verarbeitungs-Anweisungen, bedingten Abschnitten und der Dokumenttyp-Deklaration.
Beachten Sie, daß HTML und XML einander nicht ausschließen.
Sobald HTML-DTDs zur Verfügung stehen, die auf XML basieren, kann
ein Dokument, das ein HTML-Dokument ist, zugleich auch ein XML-Dokument
sein.
In gültigen Dokumenten muß dieses Attribut, wie jedes andere, deklariert werden. Die Werte dieses Attributs sind Sprachencodes gemäß Definition in der Spezifikation [IETF RFC 1766]:
Ein Beispiel für die Deklaration:
<!ATTLIST gedicht xml:lang NMTOKEN 'en'> |
Hier wird festgelegt, daß das Attribut xml:lang im Zusammenhang mit dem Element gedicht den Vorgabewert 'en' haben soll. |
<gedicht xml:lang='en'>
<titel>Indian Serenade</titel> <p>I arise from dreams of thee In the first sweet sleep of night, When the winds are breathing low, And the stars are shining bright.</p> |
Es gilt die Regel, daß Leerraum bewahrt werden muß. Auch wenn es sich um Leerraum handelt, der lediglich in den Quellcode des XML-Dokuments eingefügt wurde, damit ein menschlicher Betrachter sich besser darin orientieren kann, wird dieser Leerraum an die Anwendung weitergegeben.
Es gibt ein Standard-Attribut, mit dem besonders darauf hingewiesen
werden kann, daß der Leerraum erhalten bleiben soll. Wenn dieses
Attribut in einer Deklaration einem Element zugeordnet wird, sieht
das so aus:
<!ATTLIST gedicht xml:space (default|preserve) 'preserve'> |
<gedicht xml:space="preserve"> |
Die Aufgaben des Parsers bei der Verarbeitung eines Dokuments:
Man unterscheidet zwischen validierenden und nicht-validierenden Parsern.
Validierende Parser prüfen auf Gültigkeit, nicht-validierende
prüfen lediglich auf Wohlgeformtheit (wobei Verstöße gegen
die Wohlgeformtheit die schwerwiegenderen Verstöße sind).
XSL ist eine Sprache für Formatvorlagen (Stylesheets). Zwar können für die Formatierung von XML-Dokumenten auch Cascading Style Sheets (CSS) verwendet werden, XSL soll jedoch Möglichkeiten bieten, die über die der CSS hinausgehen. So soll es mit XSL möglich sein, in XML-Dokumenten automatisch erzeugten Text einzufügen, zum Beispiel Seitennummern, die automatisch hochgezählt werden.
Die Zeitplanung des W3C in Sachen XSL sieht so aus:
Second Working Draft:
November 1998
Third Working Draft:
Februar 1999
Proposed Recommendation: Mai 1999
Zeichenreferenzen dienen dazu, Zeichen darzustellen, die mittels Tastatur nicht eingefügt werden können.
Man kann Zeichen-Referenzen auf zweierlei Weise darstellen:
Dezimale Referenzen beginnen mit &# .
Hexadezimale Referenzen beginnen mit &#x .
http://members.aol.com/xmldoku,
Version 2.0 (vom 1.9.98)
E-Mail an: Duenhoelter@t-online.de
© Copyright 1998,
Kuno Dünhölter