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 &lt;.

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.

  

zum Seitenanfang

<< 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