Einschränkungen
(Auszug aus "XML in a Nutshell" von Elliotte Rusty Harold & W. Scott Means)
I. | Kriterien für die Wohlgeformtheit |
II. | Kriterien für die Gültigkeit |
III. | Kriterien für Namensräume |
XML 1.0 definiert nicht nur grundlegende Strukturen, die in Dokumenten und DTDs verwendet werden, sondern zusätzlich auch eine Reihe von Regeln zu deren Gebrauch. Diese Regeln betreffen verschiedene Aspekte des Umgangs mit XML. Dokumente dürfen eigentlich gar nicht als »XML« angesehen werden, wenn sie nicht alle Bedingungen für die Wohlgeformtheit erfüllen. Von Parsern wird erwartet, dass sie Verstöße gegen die verschiedenen Regeln melden, aber sie müssen nur dann die weitere Verarbeitung eines Dokuments komplett abbrechen, wenn eine Verletzung der Wohlgeformtheit auftritt. Die Bedingungen für Namensräume werden in Namenspaces in XML und nicht in XML 1.0 festgelegt.
Kriterien für die Wohlgeformtheit
Wohlgeformtheit bezieht sich auf die lexikalische Struktur eines XML-Dokuments. Wenn gewisse lexikalische Regeln eingehalten werden, akzeptiert ein XML-Parser ein XML-Dokument als wohlgeformt. Diese Regeln sollte man nicht mit der Gültigkeit eines Dokuments verwechseln: Die Wohlgeformtheit kann ohne DTD beurteilt werden. Ob ein Dokument gültig ist, kann man dagegen nur mit Hilfe seiner DTD entscheiden. Auch die Regeln der Backus-Naur-Form-Grammatik (BNF) müssen eingehalten werden. Die folgenden Abschnitte enthalten alle Kriterien für Wohlgeformtheit, die Parser für XML 1.0 verifizieren, sowie den entsprechenden Text aus der Spezifikation von XML 1.0.
Parameter-Entities in der internen Teilmenge der DTD
Auszug aus der Spezifikation
Im internen Teil der DTD sind Parameter-Entities nur da erlaubt, wo auch Markup-Deklarationen vorkommen dürfen, aber nicht innerhalb von Markup-Deklarationen. (Das gilt nicht für Referenzen, die selbst in externen Parameter-Entities stehen, oder für die externe Teilmenge der DTD.)
Beschreibung
Parameter-Entities dürfen nur in der externen Teilmenge der DTD zur Bildung von Markup-Deklarationen verwendet werden. In der internen Teilmenge der DTD dürfen sie lediglich durch vollständige Markup-Deklarationen ersetzt werden.
Externe DTD-Teilmenge
Auszug aus der Spezifikation
Falls die DTD eine externe Teilmenge enthält, muss diese zur Produktionsregel extSubset passen.
Beschreibung
Die Produktionsregel extSubset legt fest, welcher Typ von Deklaration in der externen Teilmenge enthalten sein darf. Im Allgemeinen bedeutet diese Regel, dass die externe Teilmenge der DTD nur vollständige Deklarationen oder Referenzen auf Parameter-Entities enthalten darf. Eine genauere Beschreibung der Produktionsregel extSubset finden Sie in der EBNF-Grammatik auf der Seite Grammatik eines XML 1.0-Dokuments.
Parameter-Entities zwischen Deklarationen
Auszug aus der Spezifikation
Wird die Produktionsregel DeclSep angewandt und enthält der darauf passende Text ein Parameter-Entity, muss der das Entity ersetzende Text auf die Produktionsregel extSubsetDecl passen.
Beschreibung
Der Text, der ein Parameter-Entity ersetzt, darf unter Umständen Deklarationen enthalten, die ungültig wären, wenn man denselben Text direkt einfügen würde. Parameter-Entities im internen Teil der DTD sind innerhalb von Deklarationen nicht erlaubt. Diese Regel gilt jedoch nicht, wenn die Deklarationen selbst innerhalb von Parameter-Entities stehen.
Zusammenhang von Elementtypen
Auszug aus der Spezifikation
Der Name im End-Tag eines Elements muss mit dem Namen des Start-Tags übereinstimmen.
Beschreibung
Die Verschachtelung von Elementen muss korrekt sein, insbesondere muss es zu jedem Start-Tag ein entsprechendes End-Tag geben.
Eindeutige Attribut-Spezifikationen
Auszug aus der Spezifikation
Innerhalb eines Start-Tags darf kein Attributname mehr als einmal vorkommen. Dies gilt auch für leere Elemente.
Beschreibung
Innerhalb eines Elements müssen Attributnamen eindeutig sein.
Ausschluss von Referenzen auf externe Entities
Auszug aus der Spezifikation
Attributwerte dürfen keine direkten oder indirekten Referenzen auf externe Entities enthalten.
Beschreibung
XML-Parser generieren eine Fehlermeldung, wenn sie Referenzen auf externe zu ersetzende Entities entdecken, die innerhalb von Attributwerten vorkommen.
Kein < in Attributwerten
Auszug aus der Spezifikation
Innerhalb eines Attributwerts darf der ein Entity ersetzende Text kein < enthalten. Dies gilt für direkte und indirekte Referenzen. Eine Ausnahme gilt nur für die Zeichenfolge <.
Beschreibung
Diese Restriktion soll das Parsen von XML-Daten erleichtern. Da Attributwerte auf diese Weise nicht so aussehen können, als ob sie Elementdaten enthalten, müssen einfache Parser nicht nach wörtlich verwendeten Strings suchen. Einfache Parser können daher nur durch eine Suche nach den Zeichen < und > feststellen, ob Aufbau und Verschachtelung des Markup korrekt sind.
Gültige Zeichen
Auszug aus der Spezifikation
Die Zeichen, auf die eine Zeichen-Referenz verweist, müssen auf die Produktionsregel Char passen.
Beschreibung
Jedes Zeichen, das von einem XML-Parser generiert wird, muss ein echtes Zeichen sein. Es gibt einige wenige Unicode-Zeichen, die als XML-Zeichen nicht gültig sind.
Deklaration eines Entitys
Auszug aus der Spezifikation
In Dokumenten ohne DTD bzw. ohne externe DTD-Teilmenge, die zusätzlich keine Referenzen auf Parameter-Entities enthalten, oder in Dokumenten mit standalone='yes' gilt: Wird eine Entity-Referenz außerhalb des externen Teils der DTD oder eine Parameter-Entity-Referenz benutzt, muss der referenzierte Name in einer Entity-Deklaration stehen, die nicht im externen Teil der DTD und nicht in einem Parameter-Entity steht. Eine Ausnahme stellen die folgenden Namen dar, die in keinem wohlgeformten Dokument deklariert werden müssen: amp, lt, gt, apos, quot. Die Deklaration eines Parameter-Entity muss vor den Referenzen auf das Entity stehen. Analog muss die Deklaration eines allgemeinen Entity vor den Referenzen stehen, die im Vorgabewert der Deklaration einer Attributliste stehen. Beachten Sie in diesem Zusammenhang, dass nicht-validierende Prozessoren nicht verpflichtet sind, Deklarationen zu lesen und zu verarbeiten, sofern diese im externen Teil der DTD oder in externen Parameter-Entities stehen. Für solche Dokumente entfällt das Wohlgeformtheitskriterium, dass ein Entity deklariert sein muss. Eine Ausnahme stellt der Fall standalone='yes' dar.
Beschreibung
Dieses lange Kriterium gibt die einzigen Situationen an, in denen eine Entity-Referenz vorkommen darf, ohne dass es eine entsprechende Deklaration gibt. Da ein nicht-validierender Parser den externen Teil der DTD nicht unbedingt lesen muss, sollte der Parser im Zweifelsfall davon ausgehen, dass das Dokument wohlgeformt ist, und annehmen, das Entity sei deklariert.
Geparstes Entity
Auszug aus der Spezifikation
Eine Referenz auf ein Entity muss den Namen eines geparsten Entitys enthalten. Ungeparste Entities dürfen nur in Attributwerten verwendet werden, deren Typ als ENTITY oder ENTITIES deklariert wurde.
Beschreibung
Da der Parser nur Entities einsetzen kann, die er zuvor auch gelesen hat, sollten Sie nicht versuchen, ihn auszutricksen.
Keine Rekursion
Auszug aus der Spezifikation
Ein geparstes Entity darf sich nicht selbst rekursiv referenzieren, weder direkt noch indirekt.
Beschreibung
Lassen Sie beim Strukturieren Ihrer Entities Vorsicht walten; stellen Sie sicher, dass Sie nicht unbeabsichtigt eine zirkuläre Referenz erstellen:
<!ENTITY a "&b;">
<!ENTITY b "&c;">
<!ENTITY c "&a;"> <!--falsch, c referenziert sich indirekt selbst!-->
In der DTD
Auszug aus der Spezifikation
Referenzen auf Parameter-Entities dürfen nur in der DTD vorkommen.
Beschreibung
Dieses Kriterium ist einleuchtend, weil das Zeichen % außerhalb der DTD kein Sonderzeichen ist. Innerhalb des Dokuments ist deswegen zum Beispiel das folgende Element völlig in Ordnung:
<ok>%noproblem;</ok>
Der Parser gibt den Text %noproblem; in diesem Fall ohne Modifikationen weiter, es wird keine Fehlermeldung generiert.
Kriterien für die Gültigkeit
Die folgenden Abschnitte enthalten alle Gültigkeitskriterien, die ein validierender Parser sicherzustellen hat. Jeder dieser Abschnitte enthält den entsprechenden Text aus der Spezifikation von XML 1.0 sowie eine kurze Erklärung des Kriteriums.
Typ des Wurzelelements
Auszug aus der Spezifikation
Der in der DTD angegebene name muss zugleich der Name des Wurzelelements sein.
Beschreibung
Die Deklaration !DOCTYPE enthält den Namen des Wurzelelements. Dieser Name muss mit dem Namen des Wurzelelements in dem Dokument übereinstimmen.
Korrekte Verschachtelung von Deklarationen und Parameter-Entities
Auszug aus der Spezifikation
Der ein Parameter-Entity ersetzende Text muss korrekt mit Markup-Deklarationen verschachtelt sein. Das bedeutet: Wenn das erste oder das letzte Zeichen einer Markup-Deklaration im das Entity ersetzenden Text enthalten ist, müssen bereits beide im Text enthalten sein.
Beschreibung
Dieses Kriterium bedeutet, dass man kein Parameter-Entity definieren kann, das eine DTD-Deklaration vervollständigt und eine andere beginnt. Das folgende XML-Fragment wäre zum Beispiel ein Verstoß gegen dieses Kriterium:
<!ENTITY % hoert_hier_auf ">">
<!ENTITY % bad "funktioniert nicht" %hoert_hier_auf; <!--falsch!-->
Deklaration eines Standalone-Dokuments
Auszug aus der Spezifikation
Die Deklaration eines Standalone-Dokuments muss den Wert no enthalten, wenn irgendeine externe Markup-Deklaration eines der folgenden Kriterien erfüllt: Eine Attributdeklaration enthält einen Vorgabewert, und das Dokument enthält ein Element, in dem dieses Attribut fehlt, oder andere Entities als amp, lt, gt, apos und quot werden im Dokument verwendet, oder es gibt im Dokument ein Attribut, dessen Wert sich durch Normalisierung ändert, die in der externen Markup-Deklaration angegeben ist, oder es gibt im Dokument ein Element, das ignorierbaren Whitespace (Ignorable White Space) enthält und als Element mit Unterelementen deklariert ist.
Beschreibung
Man kann diese komplizierte Liste von potenziellen Verletzungen des Begriffs ungefähr so übersetzen: »Wenn es eine externe Teilmenge in Ihrer DTD gibt, dann stellen Sie sicher, dass das Dokument von keiner der dortigen Deklarationen abhängt, bevor Sie standalone='yes' in der XML-Deklaration schreiben.« Eine noch einfachere Übersetzung wäre: »Wenn Ihr Dokument eine externe DTD-Teilmenge enthält, dann setzen Sie standalone auf no.«
Gültigkeit eines Elements
Auszug aus der Spezifikation
Ein Element heißt gültig, wenn es eine die Produktionsregel elementdecl erfüllende Deklaration mit dem Namen des Elementtyps gibt und eine der folgenden Bedingungen zutrifft:
- Die Deklaration passt auf die Produktionsregel EMPTY, und das Element enthält keinen Inhalt.
- Die Deklaration passt auf die Produktionsregel children, und die Abfolge der Kindelemente passt auf die Sprache, die von dem regulären Ausdruck im Inhalt der Deklaration definiert wird. Dabei ist Whitespace zwischen dem Start-Tag und dem ersten Kindelement, zwischen den einzelnen Kindelementen oder zwischen dem letzten Kindelement und dem End-Tag erlaubt. Whitespace-Zeichen sind Zeichen, die auf die Produktionsregel S passen. Beachten Sie, dass ein CDATA-Abschnitt, der nur Whitespace enthält, die Produktionsregel S nicht erfüllt und demnach an den hier angegebenen Stellen nicht erlaubt ist.
- Die Deklaration passt auf die Produktionsregel Mixed, und der Inhalt besteht aus Zeichen und Kindelementen, deren Typen in der Deklaration angegeben sind.
- Die Deklaration passt auf die Produktionsregel ANY, und die Typen der Kindelemente sind allesamt deklariert.
Beschreibung
Wenn Sie ein Dokument benutzen, das eine DTD mit Element-Deklarationen beinhaltet, stellen Sie sicher, dass die in Ihrem Dokument vorkommenden Elemente die in der DTD angegebenen Regeln erfüllen.
Typ und Wert eines Attributs
Auszug aus der Spezifikation
Ein Attribut muss deklariert sein, und sein Wert muss dem deklarierten Typ entsprechen.
Beschreibung
Alle Attribute, die zu Elementen in einem gültigen XML-Dokument angegeben werden, müssen in der DTD deklariert werden. Dazu zählen auch die Attribute xml:space und xml:lang. Wenn Sie ein Attribut zu einem Element deklarieren, stellen Sie sicher, dass jede Instanz dieses Attributs einen Wert hat, der dem angegebenen Typ entspricht. (Mögliche Attributtypen werden im Abschnitt Deklaration einer Attributliste der Seite Grundbegriffe der XML-Syntax beschrieben.)
Eindeutigkeit einer Elementtyp-Deklaration
Auszug aus der Spezifikation
Kein Elementtyp darf mehr als einmal deklariert werden.
Beschreibung
Im Unterschied zur Deklaration von Entities und Attributen dürfen Elementtypen nur einmal deklariert werden.
Korrekte Verschachtelung von Gruppen und Parameter-Entities
Auszug aus der Spezifikation
Der ein Parameter-Entity ersetzende Text muss korrekt mit den durch Klammern gebildeten Gruppen verschachtelt sein. Mit anderen Worten: Kommt die öffnende oder schließende Klammer einer auf die Produktionsregeln choice, seq oder Mixed passenden Gruppe in dem Text vor, der ein Parameter-Entity ersetzt, müssen auch beide in dem ersetzenden Text stehen.
Zur Vereinfachung gilt: Wenn eine Referenz auf ein Parameter-Entity in einer auf die Produktionsregeln choice, seq oder Mixed passenden Gruppe vorkommt, soll der ersetzende Text wenigstens ein Nicht-Whitespace-Zeichen enthalten, und weder das erste noch das letzte dieser Zeichen soll ein Verbindungszeichen (| oder ,) sein.
Beschreibung
Dieses Kriterium beschränkt das Verfahren, wie Parameter-Entities zur Bildung von Element-Deklarationen benutzt werden können. Es ist mit dem Kriterium »Korrekte Verschachtelung von Deklarationen und Parameter-Entities.« dahingehend vergleichbar, dass Parameter-Entities nicht dazu verwendet werden dürfen, mit Klammern gebildete Ausdrücke zu schließen oder neue zu öffnen. Der XML-Autor soll daran gehindert werden, signifikante Syntax-Elemente in Parameter-Entities zu verstecken.
Verhinderung der Duplizierung von Typen
Auszug aus der Spezifikation
In der Deklaration eines Elements mit gemischtem Inhalt darf jeder Name nur einmal auftauchen.
Beschreibung
Der Name eines Elementtyps darf nur einmal in einer Deklaration mit gemischtem Inhalt verwendet werden.
ID
Auszug aus der Spezifikation
Werte vom Typ ID müssen auf die Produktionsregel Name passen. Kein Name darf innerhalb eines XML-Dokuments mehr als einmal als Wert dieses Typs auftreten. Mit anderen Worten: ID-Werte müssen die sie enthaltenden Elemente eindeutig kennzeichnen.
Beschreibung
Keine zwei Werte eines Attributs vom Typ ID dürfen denselben Wert haben. Dieses Kriterium bezieht sich nicht auf einen bestimmten Elementtyp, sondern global auf das gesamte Dokument.
Eindeutigkeit der ID pro Elementtyp
Auszug aus der Spezifikation
Kein Elementtyp darf mehr als ein Attribut vom Typ ID enthalten.
Beschreibung
Jedes Element kann höchstens ein Attribut vom Typ ID enthalten.
Default-Werte von ID-Attributen
Auszug aus der Spezifikation
Ein Attribut vom Typ ID muss #IMPLIED oder #REQUIRED als Default-Wert haben.
Beschreibung
Um Duplizierung zu vermeiden, ist es unmöglich, ein Attribut vom Typ ID als #FIXED zu deklarieren oder einen Default-Wert dafür anzugeben.
IDREF
Auszug aus der Spezifikation
Werte eines Attributs vom Typ IDREF müssen auf die Produktionsregel Name passen, und Werte eines Attributs vom Typ IDREFS müssen auf die Produktionsregel Names passen. Ferner muss jeder Name dem Wert eines Attributs vom Typ ID zu einem Element im XML-Dokument entsprechen, d.h., IDREF-Werte müssen dem Wert eines ID-Attributs entsprechen.
Beschreibung
Eine ID-Referenz muss sich auf eine tatsächlich im XML-Dokument enthaltene ID beziehen.
Name eines Entitys
Auszug aus der Spezifikation
Werte der Typen ENTITY bzw. ENTITIES müssen auf die Produktionsregeln Name bzw. Names passen. Jeder Name muss zugleich der Name eines ungeparsten Entitys sein, das in der DTD deklariert wurde.
Beschreibung
Attribute, die mit Referenzen auf Entities deklariert sind, müssen Referenzen auf vom Parser nicht gelesene Entities enthalten, die in der DTD deklariert wurden.
Namenstoken
Auszug aus der Spezifikation
Werte vom Typ NMTOKEN bzw. NMTOKENS müssen auf die Produktionsregeln Nmtoken bzw. Nmtokens passen.
Beschreibung
Attribute, die mit einem oder mehreren Namen als Inhalt deklariert sind, müssen XML-Namenstoken enthalten.
Notationsattribut
Auszug aus der Spezifikation
Werte dieses Typs müssen auf einen der in der Deklaration enthaltenen Notationsnamen passen. Alle in der Deklaration enthaltenen Notationsnamen müssen zuvor durch eine Deklaration bekannt gemacht sein.
Beschreibung
In Attributen vorkommende Notationsnamen müssen Namen enthalten, die in der DTD deklarierte Notationen referenzieren.
Eine Notation pro Elementtyp
Auszug aus der Spezifikation
Kein Elementtyp darf mit mehr als einem Attribut NOTATION spezifiziert werden.
Beschreibung
Ein Element darf nur ein Attribut enthalten, das mit dem Attributtyp NOTATION deklariert wurde. Dieses Kriterium gewährleistet die Rückwärtskompatibilität zu SGML.
Keine Notation in leeren Elementen
Auszug aus der Spezifikation
Aus Kompatibilitätsgründen darf ein Attribut vom Typ NOTATION nicht in einem Element enthalten sein, das als EMPTY deklariert wurde.
Beschreibung
Leere Elemente dürfen keine Attribute vom Typ NOTATION enthalten. Dieses Kriterium soll die Kompatibilität zu SGML gewährleisten.
Aufzählungen
Auszug aus der Spezifikation
Werte dieses Typs müssen auf eines der in der Deklaration angegebenen Nmtoken passen.
Beschreibung
Ein Attribut vom Typ Aufzählung muss einen der in der Deklaration angegebenen Werte enthalten.
Erforderliche Attribute
Auszug aus der Spezifikation
In der Deklaration des Default-Werts bezeichnet das Schlüsselwort #REQUIRED ein Attribut, das in jedem Element des angegebenen Typs enthalten sein muss.
Beschreibung
Erforderliche Attribute müssen im Dokument auftauchen. Attributwerten mit dem Default-Wert #REQUIRED in der DTD muss im XML-Dokument ein Wert zugewiesen werden.
Korrektheit eines Attributs mit vorgegebenem Default-Wert
Auszug aus der Spezifikation
Wird in der Deklaration eines Attributs ein bestimmter Wert als Default-Wert vorgegeben, muss dieser Wert die lexikalischen Kriterien des jeweiligen Attributtyps erfüllen.
Beschreibung
Wenn man einen Vorgabewert für ein Attribut angibt, gelten für diesen Vorgabewert dieselben Regeln wie für die innerhalb des Dokuments eingesetzten Werte.
Attribute mit festem Default-Wert
Auszug aus der Spezifikation
Wenn ein Attribut mit dem Schlüsselwort #FIXED als Default-Wert deklariert wurde, müssen alle Instanzen dieses Attributs den angegebenen Wert haben.
Beschreibung
Wenn Sie einen Attributwert mit #FIXED vorgeben, darf im Attribut kein anderer als der angegebene Wert eingesetzt werden.
Korrekte Verschachtelung von bedingten Abschnitten und Parameter-Entities
Auszug aus der Spezifikation
Wenn der ein Parameter-Entity ersetzende Text eine der zu einem bedingten Abschnitt gehörenden Sequenzen <![, [ oder ]]> enthält, muss er auch die anderen Sequenzen enthalten, die den bedingten Abschnitt bilden.
Beschreibung
Wenn Sie in ein Parameter-Entity den Anfang eines bedingten Abschnitts einbetten, müssen Sie auch den Rest des Abschnitts einbetten.
Verwendung deklarierter Entities
Auszug aus der Spezifikation
Wenn ein Nicht-Standalone-Dokument (d.h. ein Dokument mit standalone='no') eine externe Teilmenge oder externe Parameter-Entities enthält, muss der in einer Referenz auf ein Entity angegebene Name der eines deklarierten Entitys sein. Aus Gründen der Interoperabilität sollten gültige Dokumente auch die Entities amp, lt, gt, apos und quot deklarieren, sofern sie verwendet werden. Die Deklaration eines Parameter-Entitys muss vor seiner Referenzierung erfolgen. Analog muss die Deklaration eines allgemeinen Entitys vor der Verwendung im Default-Wert einer Attributsliste stehen. Ob diese Verwendung direkt oder indirekt erfolgt, spielt dabei keine Rolle.
Beschreibung
Sowohl Deklarationen von Parameter-Entities als auch die von allgemeinen Entities müssen vor ihrer Referenzierung erfolgen. Alle Referenzen auf Entities müssen sich auf zuvor deklarierte Entities beziehen. Darüber hinaus ist es laut der Spezifikation sogar eine gute Idee, die fünf vorgegebenen allgemeinen Entities (amp, lt, gt, apos und quot) zu deklarieren. Tatsächlich macht die Deklaration von vordefinierten allgemeinen Entities die meisten Anwendungen aber nur unnötig komplex.
Verwendung deklarierter Notationen
Auszug aus der Spezifikation
Ein Name muss mit einer zuvor deklarierten Notation übereinstimmen.
Beschreibung
Externe, nicht vom Parser ersetzte Entities müssen eine Notation benutzen, die zuvor im Dokument deklariert wurde.
Eindeutigkeit einer Notation
Auszug aus der Spezifikation
Der in einer Notationsdeklaration angegebene Name muss eindeutig sein.
Beschreibung
Es ist nicht erlaubt, zwei Notationen mit demselben Namen zu verwenden.
Kriterien für Namensräume
Die folgenden Abschnitte enthalten alle Kriterien für Namensräume, die von der Namensraum-Spezifikation vorgegeben werden. Neben einem Auszug aus der Spezifikation Namensräume in XML beinhaltet jeder Abschnitt auch eine kurze Erläuterung des jeweiligen Kriteriums.
Führendes »XML«
Auszug aus der Spezifikation
Präfixe, die mit einer beliebigen Kombination der drei Buchstaben x, m und l beginnen, sind für die Verwendung in XML- oder XML-nahen Spezifikationen reserviert. Das gilt unabhängig von der Groß- oder Kleinschreibung der einzelnen Buchstaben, für »xml« also genauso wie für »XML«, »Xml« oder »xmL«
Beschreibung
Namensraum-Namen können ebenso wie die meisten anderen Namen in XML nicht mit xml beginnen, es sei denn, sie sind vom W3C definiert worden.
Deklariertes Präfix
Auszug aus der Spezifikation
Alle Namensraum-Präfixe bis auf xml und xmlns müssen in einem Namensraum-Deklarationsattribut deklariert worden sein. Die Deklaration muss entweder im Start-Tag des Elements erfolgen, in dem das Präfix benutzt wird, oder in einem seiner Elternelemente (d.h. in einem Element, in dessen Inhalt das Präfix auftritt). Das Präfix xml ist laut Definition an den Namensraum-Namen "http://www.w3.org/XML/1998/namespace" gebunden. Das Präfix xmlns wird nur zum Einbinden von Namensräumen eingesetzt und ist nicht selbst an irgendeinen Namensraum-Namen gebunden.
Beschreibung
Sie müssen alle Namensräume deklarieren, bevor Sie sie einsetzen können. Ohne Deklarationen haben die Präfixe keinerlei Bedeutung. Somit ist die Verwendung eines Präfix, das nicht deklariert wurde, ein Fehler. Der Namensraum mit dem Präfix xml ist immer definiert. Daher ist es nicht notwendig, ihn erneut zu definieren. Das Präfix xmlns, das in Namensraum-Deklarationen benutzt wird, wird nicht selbst als Namensraum-Präfix angesehen und muss aus diesem Grund nicht deklariert werden.
<< zurück | vor >> |
Tipp der data2type-Redaktion: Zum Thema XML bieten wir auch folgende Schulungen zur Vertiefung und professionellen Fortbildung an: |
Copyright © 2005 O'Reilly Verlag GmbH & Co. KG
Für Ihren privaten Gebrauch dürfen Sie die Online-Version ausdrucken.
Ansonsten unterliegt dieses Kapitel aus dem Buch "XML in a Nutshell" denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.
O’Reilly Verlag GmbH & Co. KG, Balthasarstraße 81, 50670 Köln, kommentar(at)oreilly.de