SELFHTML/Navigationshilfen XML/DTDs Dokumenttyp-Definitionen (DTDs)| SELFHTML/Navigationshilfen XML/DTDs Dokumenttyp-Definitionen (DTDs) |
Wenn Sie in HTML so etwas notieren wie <p align="center">etwas Text</p>, dann ist <p> das Element, und align ist ein Attribut, das innerhalb des <p>-Elements vorkommen kann. Solche Attribute können Sie in eigenen XML-DTDs für die dort definierten 
Elementtypen bestimmen. Bei der Definition eines Attributs geben Sie an, welche Wertzuweisungen dabei möglich sein sollen.
Beim Erstellen von DTDs müssen Sie überlegen, ob es sinnvoll ist, Daten in Attributen zu speichern oder nicht. Für viele Eigenschaften ist es durchaus sinnvoller, eigene Elementtypen zu definieren. So ist "Haarfarbe" beispielsweise eine typische natürliche Eigenschaft einer Person. Wenn nun in der Datenstruktur zur Beschreibung der Person über die Haare nichts weiter als die Haarfarbe berücksichtigt wird, dann genügt es, ein Element wie <haarfarbe>...</haarfarbe> zu definieren. Wenn aber noch weitere Haareigenschaften berücksichtigt werden sollen, etwa die Haarlänge, dann bietet es sich an, die Datenstruktur so zu definieren, dass es ein Element mit verschiedenen Attributen gibt, z.B. <haar farbe="..." laenge="...">...</haar>.
Dabei entsteht aber die Situation, dass die eigentlichen Anwendungsdaten in den Attributen stehen, sodass zwischen Anfangs- und End-Tag des Elements gar keine sinnvollen Zeichendaten mehr möglich sind. Es ist nämlich fraglich, was zwischen dem Einleitungs-Tag <haar farbe="..." laenge="..."> und dem End-Tag </haar> eigentlich stehen könnte. Sinnvoll ist es daher, nur solche Daten in Attribute zu packen, die vor allem zur reinen Datenverarbeitung dienen. Sind es dagegen Daten, die Inhalt enthalten, der z.B. am Bildschirm ausgegeben werden soll, dann ist es sinnvoller, eigene Elemente dafür zu definieren. So ließe sich die Datenstruktur <haar farbe="..." laenge="...">...</haar> beispielsweise auch in der folgenden Form abbilden:
<haar>
<haarfarbe>...</haarfarbe>
<haarlaenge>...</haarlaenge>
</haar>
 
|
Attribute werden innerhalb einer DTD nach folgendem Schema notiert:
<!ELEMENT Elementname (Inhalt)> <!ATTLIST Elementname Attributname_1 Inhalt [#REQUIRED|#IMPLIED|#FIXED "Wert"|Defaultwert] Attributname_n Inhalt [#REQUIRED|#IMPLIED|#FIXED "Wert"|Defaultwert] > |
Attribute werden in Abhängigkeit von Elementtypen definiert, d.h. nur für definierte Elementtypen können Sie Attribute definieren.
Die Definition eines Attributs beginnt mit einer öffnenden spitzen Klammer <. Dahinter folgt unmittelbar anschließend ein Ausrufezeichen ! und dahinter, in Großbuchstaben, das Schlüsselwort ATTLIST. Das Wort deutet schon an, dass Sie auch eine ganze Liste von Attributen definieren können. Ein Elementtyp kann beliebig viele Attribute haben. Alle Attribute, die Sie einem Elementtyp zuordnen wollen, notieren Sie in der Attributliste zu diesem Elementtyp. Hinter ATTLIST folgt der Name des Elementtyps, auf den sich die Attribute beziehen. Dieser Elementtyp muss in der DTD definiert sein (siehe Elemente).
Innerhalb der Attributliste ist es zweckmäßig, jede Attributdefinition in einer eigenen Zeile zu notieren. Jede Attributdefinition der Attributliste beginnt mit dem Namen des Attributs. Den Namen können Sie frei wählen. Er muss jedoch den Regeln für Namen in XML genügen. Hinter dem Namen notieren Sie Angaben zum Inhalt des Elementtyps. Diese Angaben können unterschiedlich sein und regeln, welche Werte ein Attribut haben kann. Schließlich gehört zu jedem Attribut noch eines der Schlüsselwörter #REQUIRED, #IMPLIED bzw. #FIXED mit einem angegebenen Wert, oder ein Defaultwert (mehr dazu im Abschnitt Notwendige und optionale Attribute).
Abgeschlossen wird die Attributlisten-Definition mit einer schließenden spitzen Klammer >. Die einzelnen Teile jeder Definition werden durch ein oder mehrere Leerzeichen voneinander getrennt.
|
|
Notwendige und optionale AttributeBei Attributen, die Sie in einer DTD zu einem Elementtyp definieren, müssen Sie stets angeben, ob das Attribut in dem Element vorkommen muss oder vorkommen kann. In HTML ist z.B. das Attribut src im <img>-Element zwingend notwendig. Das Attribut hspace kann im gleichen Element ebenfalls vorkommen, muss aber nicht.
<!ELEMENT ressourcen (ressource)*> <!ELEMENT ressource (#PCDATA)> <!ATTLIST ressource url CDATA #REQUIRED sprache CDATA #IMPLIED erfasst CDATA #REQUIRED geaendert CDATA #IMPLIED > |
Das Beispiel definiert als Inhalt für den Dokument-Elementtyp ressourcen einen Elementtyp namens ressource. Zu diesem Elementtyp werden vier Attribute definiert. Zwei dieser vier Attribute, nämlich die mit den Namen url und erfasst, müssen bei der Anwendung des Elementtyps notiert werden. Die beiden anderen, sprache und geaendert, können notiert werden. Notwendige Attribute kennzeichnen Sie durch den Schlüsselbezeichner #REQUIRED, und optionale Attribute durch #IMPLIED. Beide Angaben müssen jeweils am Ende einer Attribut-Definition stehen.
Für alle vier Attribute im Beispiel wird festgelegt, dass der zugewiesene Wert aus Zeichendaten besteht. Dies wird durch das Schlüsselwort CDATA kenntlich gemacht (siehe Attribute mit Zeichenwert).
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE ressourcen SYSTEM "ressourcen.dtd"> <ressourcen> <ressource url="http://alpentouren.teamone.de/" erfasst="09.11.2000"> Hypertextuell aufbereitete Beschreibung etlicher Rad-Touren über Alpenpässe </ressource> <ressource url="http://www.planetbike.co.nz/" erfasst="10.12.2000" geaendert="16.12.2000" sprache="en"> Mountain Bike Touren durch Neuseeland </ressource> </ressourcen> |
Im Beispiel werden zwei Elemente des Typs ressource notiert. Beim ersten Element werden nur die beiden notwendigen Attribute url und erfasst notiert, im zweiten Element dagegen alle vier definierten Attribute.
|
|
Attribute mit ZeichenwertJedes Attribut muss in XML eine Wertzuweisung erhalten. In vielen Fällen ist der zugewiesene Wert nicht auf einen bestimmten Wertebereich eingeschränkt, sondern kann eine unbestimmte Anzahl möglicher Werte haben. Das ist zum Beispiel der Fall, wenn das Attribut eine Kurzbeschreibung, einen numerischen Wert, einen prozentualen Wert oder eine Maßangabe enthält. Solche Attribute werden Attribute mit Zeichenwert genannt.
<!ELEMENT autos (auto)*> <!ELEMENT auto EMPTY> <!ATTLIST auto typ CDATA #REQUIRED bj CDATA #REQUIRED km CDATA #REQUIRED ps CDATA #REQUIRED vb CDATA #REQUIRED > |
Im Beispiel wird ein Elementtyp ohne Inhalt namens auto definiert. Dem Elementtyp werden fünf notwendige Attribute zugeordnet. Alle enthalten Zeichenwert. Für diesen Wert-Typ müssen Sie hinter dem Attributnamen als Attributinhalt den Schlüsselbezeichner #CDATA angeben. Zeichenwert ist eine beliebige und beliebig lange Zeichenfolge, also Text, Zahlen, und Sonderzeichen. #CDATA ist eine Abkürzung für character data, zu deutsch Zeichendaten).
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE autos SYSTEM "autos.dtd"> <autos> <auto typ="AUDI 80" bj="1992" km="125000" ps="90" vb="12500 DM" /> </autos> |
Dem Element auto werden im Anwendungsbeispiel alle definierten Attribute zugewiesen. Egal ob Zeichenketten, Zahlen oder Mischformen - alle Wertzuweisungen fallen unter das, was in XML durch CDATA abgedeckt ist.
Was als Wertzuweisung in den Attributen steht, ist bei CDATA egal. Um nur bestimmte Wertzuweisungen zu erlauben, können Sie Attribute mit festen alternativen Werten definieren.
Innerhalb von Wertzuweisungen an Attribute können Sie auch das Apostoph-Zeichen ' und das Anführungszeichen " verwenden. Diese beiden Zeichen müssen Sie dann aber unbedingt maskieren, nämlich in der Form ' für ' und " für ".
|
|
Attribute mit festen alternativen WertenAus HTML sind Ihnen vermutlich viele Attribute bekannt, die nur bestimmte Werte zulassen. So lässt das Attribut align in den Elementen, in denen es vorkommen kann, nur Werte wie left, center, right und justify zu. Solche Attribute mit bestimmten erlaubten Wertzuweisungen können Sie auch in XML definieren.
<!ELEMENT hotels (hotel)*> <!ELEMENT hotel (#PCDATA)> <!ATTLIST hotel name CDATA #REQUIRED klasse (I|II|III|IV|V) #REQUIRED einzelzimmer (ja|nein) #IMPLIED doppelzimmer (ja|nein) "ja" > |
Im Beispiel wird ein Elementtyp hotel definiert. Dem Elementtyp werden vier Attribute zugeordnet. Das erste ist ein notwendiges Attribut mit Zeichenwert. Die übrigen drei Attribute haben keinen Zeichenwert, sondern erwarten einen von bestimmten möglichen Wertzuweisungen. Die möglichen Werte werden in Klammern notiert und durch das logische "Oder", symbolisiert durch den Senkrechtstrich |, voneinander getrennt. Das Attribut klasse erlaubt auf diese Weise einen der möglichen Werte I, II, III, IV oder V. Die Attribute einzelzimmer und doppelzimmer erlauben die Wertzuweisungen ja oder nein. Zusätzlich besteht bei Attributen mit festen alternativen Werten die Möglichkeit, einen dieser Werte als Default-Wert zu definieren. Im Beispiel ist das beim Attribut doppelzimmer der Fall. Dabei wird hinter der Klammer mit den möglichen Wertzuweisungen, durch ein oder mehrere Leerzeichen getrennt und in Anführungszeichen gesetzt, einer der Werte als Default-Wert notiert - im Beispiel der Wert ja. Wenn Sie einen solchen Default-Wert notieren, ist hinterher keine Angabe mehr dazu möglich, ob das Attribut notwendig (#REQUIRED) oder optional (#IMPLIED) ist. Denn der Default-Wert bewirkt, dass das Attribut intern vom Parser als notwendig interpretiert wird. Wenn das Attribut in der Anwendung weggelassen wird, wird automatisch der Default-Wert angenommen.
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE hotels SYSTEM "hotels.dtd"> <hotels> <hotel name="Waldesruh" klasse="IV"> Hotel am Waldesrand gelegen, 150 Betten, ruhig und teuer. </hotel> <hotel name="Arabesk" klasse="II" doppelzimmer="ja" einzelzimmer="ja"> Einfaches Stadthotel, 400 Zimmer, annehmbar, ohne besonderen Komfort. </hotel> <hotel name="Fridolin" klasse="III" einzelzimmer="nein"> Hotel in zentraler Lage, 100 Betten, angenehm, gute Verkehrsanbindung. </hotel> </hotels> |
Das Beispiel zeigt drei erlaubte Anwendungen des hotel-Elements. Im ersten Fall werden nur die beiden Attribute notiert, die in der DTD als notwendig definiert wurden. Für das Attribut doppelzimmer wird intern der Default-Wert ja interpretiert.
Im zweiten Anwendungsfall wird das Attribut doppelzimmer explizit notiert, und es wird der definierte Default-Wert zugewiesen. Genaugenommen ist diese Angabe überflüssig, weil der Default-Wert die Interpretation bereits abdeckt. Die Notation entspricht etwa der Angabe align="left" in HTML, wo die Wertzuweisung left als Default-Wert definiert ist.
Das Attribut einzelzimmer, das als optional (#IMPLIED) definiert ist, erhält in den ersten beiden Anwendungsfällen gar keinen Wert. Im dritten Anwendungsfall wird es explizit auf nein gesetzt.
Wertzuweisungen an Attribute mit festen alternativen Werten dürfen keine Leerzeichen enthalten, also letztlich nicht aus mehr als einem Wort bestehen.
Es gibt auch die Möglichkeit, für ein Attribut eine bestimmte Wertzuweisung zu erzwingen. Dazu notieren Sie (Beispiel):
typ (hotel | motel) #FIXED "hotel"
Durch die Angabe #FIXED erreichen Sie, dass an das Attribut typ keine andere Wertzuweisung als hotel möglich ist, obwohl noch eine andere Möglichkeit definiert ist. Solche Konstrukte können sinnvoll sein, wenn ein Attribut zu einem späteren Zeitpunkt noch andere Werte aufnehmen können, aber schon mal "etabliert" werden soll.
|
|
Neben Attributen, mit beliebigen Zeichendaten (CDATA) als Wert oder mit festen alternativen Werten gibt es Attribute, die als Wertzuweisung Bezeichnerwerte erwarten. Bezeichnerwerte sind identifizierende Werte wie Namen oder Nummern. Zu dieser Gruppe gehören:
Attribute mit Identifikationswert
Attribute mit Identifikationsreferenzwert
Attribute mit Entity-Wert (z.B. für externe Dateireferenzen)
Attribute mit nmtoken-Wert (auch für numerische Identifikationen)
|
|
Attribute mit IdentifikationswertXML sieht eine Möglichkeit vor, dem Parser mitzuteilen, dass der zugewiesene Wert eines bestimmten Attributs dokumentweit nur einmal vorkommen darf. Dies ist ein wichtiges Feature vor allem im Hinblick auf Scriptsprachen. Denn nur bei dokumentweit eindeutigen, identifizierenden Werten ist es möglich, ein Element über den Identifikationswert anzusprechen.
<!ELEMENT buecher (buch)*> <!ELEMENT buch (#PCDATA)> <!ATTLIST buch isbn ID #REQUIRED titel CDATA #REQUIRED autor CDATA #REQUIRED > |
Im Beispiel wird ein Elementtyp buch definiert. Dem Elementtyp werden drei notwendige Attribute zugeordnet. Zwei davon enthalten Zeichenwert, einer Identifikationswert - nämlich das Attribut isbn. Um ein Attribut mit Identifikationswert zu definieren, notieren Sie bei der Definition anstelle von CDATA den Schlüsselbezeichner ID.
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE buecher SYSTEM "buecher.dtd"> <buecher> <buch isbn="nr_3-90193-3949-7" titel="Anbaggern leicht gemacht" autor="Dr. Howtodo"> Ein Anleitung zwischen Genie und Wahnsinn. </buch> <buch isbn="nr_3-90193-3950-2" titel="Anbaggern leicht gemacht II" autor="Dr. Howtodo"> Eine weitere Anleitung zwischen Genie und Wahnsinn. </buch> </buecher> |
Das Beispiel zeigt, wie zwei gleichnamige Elemente, bei denen auch Attribute den gleichen Inhalt haben können, sich doch durch ein als ID definiertes Attribut unterscheiden müssen. Ein Parser, der XML korrekt interpretiert, müsste einen Fehler melden, wenn die Wertzuweisung an das Attribut isbn im zweiten Datensatz "buch" den gleichen Wert hätte wie im ersten.
Die Wertzuweisungen an ein Attribut vom Typ ID müssen den Regeln für Namen entsprechen! Im obigen Beispiel wird den ISBN-Nummern deshalb die Zeichenfolge nr_ vorangestellt, da die eigentliche ISBN-Nummer mit einer Ziffer beginnt, was aber kein gültiger Name wäre.
Der MS Internet Explorer mit mit älterem Microsoft XML-Parser akzeptiert zwar den Typ ID, lässt aber trotzdem mehrere gleiche ID-Werte in einem Dokument zu, was nicht dem Sinn der Sache entspricht. Neuere XML-Parser von Microsoft (ab msxml3.dll) verhalten sich dagegen korrekt.
|
|
Attribute mit IdentifikationsreferenzwertWenn Sie für Elementtypen Attribute mit Identifikationswert definieren, können Sie auch Attribute definieren, deren Wert auf ein bestimmtes anderes Element verweist. Auf diese Weise können Sie durch Attribute logische Abhängigkeitsbeziehungen zwischen Elementen definieren.
<!ELEMENT liste (eintrag)*> <!ELEMENT eintrag (#PCDATA)> <!ATTLIST eintrag name ID #REQUIRED elterneintrag IDREF #IMPLIED > |
Im Beispiel wird ein Elementtyp eintrag definiert. Dieser Elementtyp könnte zum Beispiel Einträge eines Inhaltsverzeichnisses aufnehmen, das baumartige Kapitelstrukturen definiert. Diese Abhängigkeit wird im Beispiel in der Definition der Attribute ausgedrückt. Der Elementtyp eintrag erhält ein Attribut name, das als Attribut mit Identifikationswert definiert wird. Jedes Element eintrag muss in der Anwendung also einen dokumentweit eindeutigen Wert für name zugewiesen bekommen.
Ferner wird dem Element eintrag ein Attribut elterneintrag zugeordnet. Der Wert dieses Attributs muss der Definition zufolge der Name eines Eintrags sein, auf den sich das aktuelle Element bezieht. Solche Rückbeziehungen drücken Sie durch den Schlüsselbezeichner IDREF aus. Durch die beiden definierten Attribute ist es nun möglich, eine beliebige Baumstruktur abzubilden.
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE liste SYSTEM "liste.dtd"> <liste> <eintrag name="wurzel">Inhalt</eintrag> <eintrag name="einleitung" elterneintrag="wurzel">eine Einleitung</eintrag> <eintrag name="geschichte" elterneintrag="einleitung"> etwas zur Geschichte</eintrag> <eintrag name="heute" elterneintrag="einleitung">heutiger Zustand</eintrag> <eintrag name="schritte" elterneintrag="wurzel">Erste Schritte</eintrag> <eintrag name="beispiel" elterneintrag="schritte">ein kleines Beispiel</eintrag> </liste> |
Das Beispiel zeigt, wie Sie allein mit Hilfe der beiden Attribute name (als ID definiert) und elterneintrag (als IDREF definiert) eine Baumstruktur abbilden können. Die Struktur des Beispiels lässt sich optisch so darstellen:
Inhalt
Einleitung
Geschichte
heutiger Zustand
Erste Schritte
Ein kleines Beispiel
Das Attribut elterneintrag ist im Beispiel als optional (#IMPLIED) definiert. Deshalb darf es z.B. im ersten Eintrag des Beispiels (dem Eintrag mit dem Namen wurzel) entfallen.
Neben IDREF gibt es beim Definieren von Attributen mit Identifikationsreferenzwert auch noch die Pluralform IDREFS. Dadurch erlauben Sie, dass einem solchen Attribut mehrere eindeutige Bezugswerte zugewiesen werden können. Würde man im obigen Beispiel etwa definieren:
elterneintrag IDREFS #REQUIRED
Dann wäre in der Anwendung eine Zuweisung wie diese erlaubt:
<eintrag name="schritte" elterneintrag="wurzel einleitung">Erste Schritte</eintrag>
Trennen Sie dabei mehrere Zuweisungen durch Leerzeichen.
Der MS Internet Explorer mit mit älterem Microsoft XML-Parser akzeptiert zwar den Typ ID, lässt aber trotzdem mehrere gleiche ID-Werte in einem Dokument zu, was nicht dem Sinn der Sache entspricht. Neuere XML-Parser von Microsoft (ab msxml3.dll) verhalten sich dagegen korrekt.
|
|
Attribute mit Entity-Wert (z.B. für externe Dateireferenzen)Bei Attributen mit Entity-Wert wird in der Anwendung die Wertzuweisung an ein solches Attribut als Name einer definierten Entity erkannt. Der zugewiesene Wert ist dann nicht der notierte Name, sondern die Definition, die damit verknüpft ist. Diese Möglichkeit ist vor allem deshalb interessant, weil sie in XML die Art und Weise ist, um externe Dateien zu referenzieren. Stellen Sie sich eine Notierung wie <bild quelle="netz.gif"> vor. Um dem Parser mitzuteilen, dass er diesen Attributinhalt nicht einfach als Zeichenfolge, sondern als Referenz einer externen Datei interpretieren soll, ist der Umweg über die als externe Entitiy definierte Referenz erforderlich.
<!NOTATION gif PUBLIC "+//ISBN 0-7923-9432-1::Graphic Notation//NOTATION CompuServer Graphic Interchange Format//EN"> <!ENTITY netz SYSTEM "netz.gif" NDATA gif> <!ELEMENT bild EMPTY> <!ATTLIST bild quelle ENTITY #REQUIRED > |
Wie Sie sehen, ist das Einbinden einer externen Referenz etwas aufwendig. In der DTD geben Sie sowohl die Quelle der zu referenzierenden Datei an, als auch die Art, wie der entsprechende Dateityp verarbeitet werden sollte. Die Quelle definieren Sie mit der externen Entity-Anweisung (<!ENTITY...>), die Verarbeitung des Dateityps mit der Notation-Anweisung (<!NOTATION...>). Im Beispiel wird dann ein Elementtyp namens bild und dazu ein Attribut namens quelle definiert. Um ein Attribut mit Entity-Wert zu definieren, notieren Sie bei der Definition anstelle von CDATA den Schlüsselbezeichner ENTITY.
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE bild SYSTEM "bild.dtd"> <bild quelle="netz" /> |
Die Anwendung ist ganz einfach: dem Element bild wird beim Attribut quelle ein Name zugewiesen. Dieser Name ist in der DTD als Entity definiert. Durch die Definition als Attribut mit Entity-Wert wird dem Parser mitgeteilt, dass er den zugewiesenen Wert als Namen einer Entity zu interpretieren hat. Bei der Interpretation wird der zugewiesene Wert "netz" durch die damit verbundene Verknüpfung "netz.gif" ersetzt. Durch die Definition als externe Entity (mit SYSTEM) weiß der Parser außerdem, dass dieser Wert die Pfadangabe zu einer anderen Datei darstellt.
Der hier beschriebene Weg ist keine Lösung, wenn Sie erreichen möchten, dass einem Attribut eine beliebige externe Quelle zugewiesen werden kann, wie es etwa in HTML bei <img src="..."> möglich ist. So etwas kann derzeit in XML gar nicht definiert werden. In XHTML, der XML-gerechten Definition von HTML, ist das src-Attribut des img-Elements schlicht als CDATA definiert. dass ein Web-Browser dieses Attribut als Aufforderung versteht, an der entsprechenden Stelle die gewünschte Grafik anzuzeigen, ist nur im Web-Browser so programmiert - es steht jedoch nicht in der XHTML-DTD! Wenn Sie also XML-Daten direkt am Bildschirm ausgeben wollen, sind beliebige externe Referenzen ein Problem. Ein möglicher Weg, dieses Problem zu lösen, stellt XSLT dar, mit dessen Hilfe Sie XML-Daten vor der Datenausgabe in HTML übersetzen können.
Neben ENTITY gibt es beim Definieren von Attributen auch noch die Pluralform ENTITIES. Dadurch erlauben Sie, dass einem solchen Attribut mehrere Entity-Namen zugewiesen werden können. Trennen Sie dabei mehrere Zuweisungen durch Leerzeichen.
|
|
Attribute mit NamenwertSolche Attribute erwarten als Wert einen Namen, der jedoch im Gegensatz zu Attributen mit Identifikationswert nicht dokumentweit eindeutig sein muss. Der Name darf keine Leerzeichen enthalten und muss mit einem Buchstaben, einer Ziffer oder einem der Zeichen . (Punkt), - (Bindestrich), _ (Unterstrich) oder : (Doppelpunkt) beginnen.
<!ELEMENT feiertage (feiertag)*> <!ELEMENT feiertag EMPTY> <!ATTLIST feiertag datum NMTOKEN #REQUIRED ereignis CDATA #REQUIRED > |
Im Beispiel wird für ein Element feiertag eine Attributliste mit zwei Attributen datum und ereignis definiert. Das Attribut datum hat dabei Namenwert. Erreicht wird dies durch das Schlüsselwort NMTOKEN.
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE feiertage SYSTEM "feiertage.dtd"> <feiertage> <feiertag datum="6.1." ereignis="Hl. Drei Könige" /> <feiertag datum="1.5." ereignis="Arbeiterfeiertag" /> <feiertag datum="25.12." ereignis="1. Weihnachtstag" /> </feiertage> |
Das Beispiel definiert drei Feiertage mit Datum und Ereignis. Die Werte der Attribute datum entsprechen durchaus den erlaubten Regeln für den Typ NMTOKEN. In der Praxis wird dieser Typ auch gerne verwendet, um mit numerischen ID-Werten zu arbeiten, da Attribute mit Identifikationswert keine Ziffern am Anfang der Wertzuweisung zulassen.
Neben NMTOKEN gibt es beim Definieren von Attributen auch noch die Pluralform NMTOKENS. Dadurch erlauben Sie, dass einem solchen Attribut mehrere Namen zugewiesen werden können. Trennen Sie dabei mehrere Zuweisungen durch Leerzeichen.
|
|
Aus HTML kennen Sie vermutlich Konstrukte wie <hr noshade> oder <td nowrap>. Standalone-Attribute ohne Wertzuweisung also. Solche Attribute gibt es in der Syntax von XML nicht. XML sieht vor, dass jedem Attribut ein Wert zugewiesen wird. Jedes Attribut muss bei der Definition mindestens den unbestimmten Inhaltsyp CDATA erhalten. Da Attribute wie noshade eigentlich nichts weiter sind als eine Abkürzung für so etwas wie noshade="yes", empfiehlt sich bei der Definition solcher Attribute das Arbeiten mit Attribute mit festen alternativen Werten.
|
|
Zusammenhängendes Beispiel: PersonenbeschreibungMenschen haben viele Eigenschaften, daher scheint eine Personenbeschreibung ein typischer Anwendungsfall für den Einsatz von Attributen zu sein. Doch bei der Umsetzung in XML müssen Sie dabei die Überlegungen berücksichtigen, die im Abschnitt Allgemeines zu Attributen besprochen wurden.
Das folgende Beispiel zeigt ein Daten-Design, bei dem alle Nutzdaten in Attributen gespeichert werden.
<!ELEMENT personendatenbank (person)*> <!ELEMENT person (bio,sozio)> <!ATTLIST person name CDATA #REQUIRED > <!ELEMENT bio (augen,haar,haut,gewicht,blutgruppe)> <!ELEMENT augen EMPTY> <!ATTLIST augen farbe CDATA #REQUIRED > <!ELEMENT haar EMPTY> <!ATTLIST haar farbe CDATA #REQUIRED bemerkung CDATA #IMPLIED > <!ELEMENT haut EMPTY> <!ATTLIST haut farbe CDATA #REQUIRED bemerkung CDATA #IMPLIED > <!ELEMENT gewicht EMPTY> <!ATTLIST gewicht kg CDATA #REQUIRED > <!ELEMENT blutgruppe EMPTY> <!ATTLIST blutgruppe typ (A|B|0|AB) #REQUIRED > <!ELEMENT sozio (sprache,stand,passport)> <!ELEMENT sprache EMPTY> <!ATTLIST sprache lang CDATA #REQUIRED kurz (de|en|fr|es|pt|it) #IMPLIED > <!ELEMENT stand EMPTY> <!ATTLIST stand typ (ledig|verheiratet|verwitwet) #REQUIRED > <!ELEMENT passport EMPTY> <!ATTLIST passport nr NMTOKEN #REQUIRED > |
Anzeigebeispiel: So sieht's aus (XML-fähiger Browser zeigt z.B. die Datenstruktur an)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE personendatenbank SYSTEM "personendatenbank.dtd">
<personendatenbank>
<person name="Bruno Buddelmann">
<bio>
<augen farbe="graublau" />
<haar farbe="blond" bemerkung="hin und wieder getönt" />
<haut farbe="weiß" />
<gewicht kg="84" />
<blutguppe typ="A" />
</bio>
<sozio>
<sprache lang="deutsch" kurz="de" />
<stand typ="ledig" />
<passport nr="38385409398" />
</sozio>
</person>
</personendatenbank>
|
Die Beispiel-DTD definiert einen Dokument-Elementtyp personendatenbank der beliebig viele Elemente des Typs person enthalten kann. Dieser Elementtyp besteht seinerseits aus Elementinhalt. Ferner erhält der Elementtyp person ein immer erforderliches Attribut name, in dem der Name der Person notiert werden soll. Die beiden Elementtypen bio und sozio, die den Elementinhalt von person darstellen, sind selbst wieder Elementtypen mit Elementinhalt. Der Elementtyp bio besteht aus der festen Elementtypfolge augen,haar,haut,gewicht,blutgruppe, und der Elementtyp sozio aus der festen Elementtypfolge sprache,stand,passport. Auf diese Weise entsteht ein strukturierter Datensatz person.
Die untergeordneten Elementtypen sind ausnahmslos mit dem Schlüsselwort EMPTY als Elemente ohne Inhalt definiert. Es werden jedoch für all diese Elementtypen Attribute definiert, in denen bei der Anwendung Daten gespeichert werden können. Die meisten dieser Attribute werden mit Hilfe des Schlüsselworts REQUIRED als notwendige Attribute definiert, einige mit IMPLIED als optionale Attribute (siehe notwendige und optionale Attribute).
In der Anwendung des Beispiels ist die typische Notation für Tags ohne End-Tags erkennbar (zur Notation solcher Elemente siehe auch den Abschnitt Tags, Attribute und Wertzuweisungen). Die Beispieldatei person.xml enthält im Beispiel genau einen Datensatz person. Die Datei könnte laut DTD-Definition jedoch beliebig viele solcher Datensätze enthalten, wobei jedoch alle Datensätze den gleichen Elementaufbau haben müssen.
|
| |
 |
Entities für Textbausteine und Umschreibungen
|
 |
Elemente und Verschachtelungsregeln
|
| SELFHTML/Navigationshilfen XML/DTDs Dokumenttyp-Definitionen (DTDs) |
© 2001 
selfhtml@teamone.de
