http://www.schumacher-netz.de/TR/2004/REC-xml-names11-20040204-de.html
Stefan Schumacher, schumacher-netz.de <[email protected]>
Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Texts. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen beim Übersetzer. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.
Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an den Übersetzer.
Weitere Übersetzungen zum weitreichenden Themenfeld XML & Co finden Sie auf schumacher-netz.de und edition-w3c.de.
Bitte lesen sie die Errata zu diesem Dokument, die einige normative Korrekturen enthalten können.
Siehe auch Übersetzungen.
Dieses Dokument ist auch in den folgenden Formaten erhältlich: XML.
Copyright © 2004 W3C® ( MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
XML-Namensräume bietet eine einfache Methode, Element- und Attributnamen, die in Extensible Markup Language-Dokumenten verwendet werden, zu qualifizieren, indem sie mit Namensräumen verknüpft werden, die durch IRI-Verweise identifiziert werden.
Dieser Abschnitt beschreibt den Status dieses Dokuments zur Zeit seiner Veröffentlichung. Andere Dokumente können dieses Dokument ablösen. Eine Liste der aktuellen W3C-Veröffentlichungen und die aktuelle Revision dieses technischen Berichts kann im Index der technischen Berichte des W3C unter http://www.w3.org/TR/ gefunden werden.
Diese Dokument ist eine Empfehlung des W3C. Es wurde von W3C-Mitgliedern und anderen intessierten Gruppen überprüft und vom Direktor als W3C-Empfehlung anerkannt. Es ist ein stabiles Dokument und kann als Referenzmaterial verwendet werden oder als normative Referenz von anderen Dokumenten zitiert werden. Die Rolle des W3C bei der Erstellung dieser Empfehlung ist es, Aufmerksamkeit auf die Spezifikation zu lenken und deren breite Anwendung zu fördern. Dies steigert die Funktionalität und die Interoperabilität des Webs.
Dieses Dokument ist ein Produkt der W3C XML Activity. Die englische Version dieser Spezifikation ist die einzige normative Version. Übersetzungen dieses Dokuments können jedoch unter http://www.w3.org/2003/03/Translations/byTechnology?technology=xml-names11 eingesehen werden.
Eine Dokumentation zu eventuellem geistigen Eigentum, der relevant für diese Empfehlung ist, wäre auf der öffentlichen Seite für IPR-Bekanntmachungen zu finden.
Bekannte Implementierungen sind im Namensräume 1.1-Implementierungsbericht dokumentiert. Eine Testsuite ist ebenfalls erhältlich; auf der Seite XML Test Suite.
Bitte melden Sie Fehler in diesem Dokument an [email protected]; öffentliche Archive sind verfügbar. Die Liste der Errata für dieses Dokument ist verfügbar unter http://www.w3.org/XML/2004/xml-names11-errata.
1 Motivation und Zusammenfassung
1.1 Anmerkung zur Schreibweise und Verwendung
2 XML-Namensräume
2.1 Grundlegende Konzepte
2.2 Verwendung von IRIs als Namensraum-Namen
2.3 IRI-Verweise vergleichen
3 Namensräume deklarieren
4 Qualifizierte Namen
5 Qualifizierte Namen verwenden
6 Elementen und Attributen Namensräume
zuweisen
6.1 Geltungsbereich eines Namensraums
6.2 Voreingestellte Namensräume
6.3 Einzigartigkeit von Attributen
7 Konformität von Dokumenten
8 Konformität von Prozessoren
9 Internationalized Resource Identifiers (IRIs)
A Normative Quellen
B Andere Quellen (nicht normativ)
C Die interne Struktur von XML-Namensräume (nicht normativ)
D Veränderungen seit Version 1.0 (nicht normativ)
E Danksagungen (nicht normativ)
Wir stellen uns Anwendungen der Extensible Markup Language (XML) vor, in denen ein einziges XML-Dokument Elemente und Attribute enthält (hier auch Markup-Vokabular genannt), die für mehrere Software-Module definiert sind und von ihnen verwendet werden. Eine Motivation hierfür ist Modularität: besteht ein Markup-Vokabular, das wohl verstanden ist und für welches es nützliche Software gibt, ist es besser, dieses Markup wieder zu verwenden als es neu zu erfinden.
Dokumente, die mehrere Markup-Vokabulare enthalten, verursachen einerseits Probleme mit der Erkennung und andererseits mit möglichen Kollisionen. Softwaremodule müssen in der Lage sein, die Elemente und Attribute zu erkennen, für deren Verarbeitung sie entwickelt wurden, auch im Fall von auftretenden Kollisionen, wenn Markup, das für eine andere Software verwendet werden soll, die gleichen Elementnamen oder Attributnamen verwendet.
Diese Überlegungen erfordern, dass Namen im Dokumentaufbau so gewählt werden sollten, dass ein Konflikt zwischen Namen verschiedener Markup-Vokabulare verhindert wird. Diese Spezifikation beschreibt einen Mechanismus, XML-Namensräume, der dieses Ziel erfüllt, indem er Elementen und Attributen erweiterte Namen zuweist.
Sind die Schlüsselworte MÜSSEN, NICHT DÜRFEN, ERFORDERLICH, SOLLEN, NICHT SOLLEN und KÖNNEN in diesem Dokument BETONT, sind sie zu interpretieren, wie in [Keywords] beschrieben.
Beachten Sie, dass viele der Nonterminals in dieser Produktion nicht hier, sondern in der XML-Spezifikation [XML] definiert sind. Haben hier definierte Nonterminals den gleichen Namen wie Nonterminals, die in der XML-Spezifikation definiert sind, entsprechen die Produktionen hier in allen Fällen einer Untermenge der Zeichen, die den diesbezüglichen dort entsprechen.
Etwas einfacher ausgedrückt:
Tragen hier definierte Nonterminals den gleichen Namen wie
in der XML-Spezifikation, so entsprechen die Definitionen hier, denen
in der XML-Spezifikation oder einer Untermenge davon.
In den Produktionen dieses Dokuments, ist die NSC
eine
Namensraumbeschränkung
(von: NameSpace Constraint), eine
der Regeln, der Dokumente entsprechen
MÜSSEN,
um konform zu dieser Spezifikation zu sein.
[Definition: Ein XML-Namensraum wird durch einen IRI-Verweis identifiziert; Element- und Attributnamen können in einem XML-Namensraum angesiedelt werden, indem der Mechanismus verwendet wird, der in dieser Spezifikation beschrieben ist.]
[Definition: Ein erweiterter Name ist ein Paar aus einem Namensraum-Namen und einem lokalem Namen.] [Definition: Für einen Namen N in einem Namensraum, der durch den IRI I identifiziert wird, ist der Namensraum-Name I. Für einen Namen N, der nicht in einem Namensraum ist, hat der Namensraum-Name keinen Wert.] [Definition: In beiden Fällen ist der lokale Name N.] Es ist diese Kombination aus einem global verwalteten IRI-Namensraum und dem lokalen Namen des Vokabulars, die effektiv die Namenskonflikte verhindert.
IRI-Verweise können Zeichen enthalten, die in Namen nicht gestattet sind, und sind oft ungünstig lang. So werden erweiterte Namen nicht direkt verwendet, um Elemente und Attribute in XML-Dokumenten zu benennen. Stattdessen werden qualifizierte Namen verwendet. [Definition: Ein qualifizierter Name ist ein Namensubjekt zur Namensraum-Interpretation.] In Dokumenten, die konform zu dieser Spezifikation sind, erscheinen Element- und Attributnamen als qualifizierte Namen. Syntaktisch sind sie entweder Namen mit Präfix oder Namen ohne Präfix. Eine Attribut basierte Deklarationssyntax wird gegeben, um Präfixe an Namensraum-Namen zu binden und um einen voreingestellten Namensraum an Elementnamen ohne Präfix zu binden; diese Deklarationen gelten für die Elemente, an denen sie verwendet werden, so dass verschiedene Bindungen in verschiedenen Teilen des Dokuments gelten können. Zu dieser Spezifikation konforme Prozessoren MÜSSEN diese Deklarationen und Präfixe erkennen und entsprechend handeln.
Die leere Zeichenkette, auch wenn sie ein gültiger IRI-Verweis ist, kann nicht als Namensraum-Name verwendet werden.
Die Verwendung von relativen IRI-Verweisen in Namensraum-Deklarationen wird missbilligt, eingeschlossen sind auch Verweise im gleichen Dokument.
Anmerkung:
Diese Missbilligung relativer URI-Verweise wurde von einem W3C XML Plenary Ballot beschlossen [Relative URI deprecation]. Es deklariert ebenso, dass "spätere Spezifikationen wie DOM, XPath usw. keine Interpretation für diese definieren".
IRI-Verweise, die Namensräume identifizieren, werden verglichen, wenn festgestellt werden soll, ob ein Name zu einem gegebenen Namensraum gehört, und ob zwei Namen zu dem gleichen Namensraum gehören. [Definition: Die beiden IRIs werden als Zeichenkette behandelt, und sie sind identisch, wenn und nur wenn die Zeichenketten identisch sind. Das ist der Fall, wenn sie aus der gleichen Zeichenfolge bestehen.] Der Vergleich unterscheidet zwischen Groß- und Kleinschreibung und es wird kein %-Ersetzen ausgeführt oder rückgängig gemacht.
Eine Folge dessen ist, dass IRI-Verweise, die in diesem Sinn nicht identisch sind, zu der gleichen Quelle auflösen können. Beispielsweise IRI-Verweise, die sich nur in der Großschreibung oder im %-Ersetzen unterscheiden, oder IRI-Verweise in externen Entities, welche verschiedene Base URIs haben (aber beachten Sie, dass relative IRIs als Namensraum-Namen missbilligt werden).
In einer Namensraum-Deklaration, ist der IRI-Verweis der normalisierte Wert des Attributs, das Ersetzen der XML-Zeichen und Entity-Verweise wurde vor jedem Vergleich schon ausgeführt.
Beispiele:
Alle IRI-Verweise unten sind verschieden, wenn es um die Identifikation von Namensräumen geht, weil sie sich in der Großschreibung unterscheiden:
http://www.example.org/wine
http://www.Example.org/wine
http://www.example.org/Wine
Die folgenden IRI-Verweise sind ebenfalls verschieden, wenn es um die Identifikation von Namensräumen geht:
http://www.example.org/rosé
http://www.example.org/ros%c3%a9
http://www.example.org/ros%c3%A9
http://www.example.org/ros%C3%a9
http://www.example.org/ros%C3%A9
So auch diese:
http://www.example.org/~wilbur
http://www.example.org/%7ewilbur
http://www.example.org/%7Ewilbur
Wurde das Entity eacute so definiert, dass es é ist,
enthalten die Start-Tags unten alle Namensraum-Deklarationen, die das
Präfix p an den gleichen IRI-Verweis
http://example.org/rosé
binden.
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
<p:foo xmlns:p="http://example.org/rosé">
Da ein Verwechslungsrisiko zwischen IRIs besteht, die nach der Dereferenzierung gleich sind, wird in Namensraumnamen dringend davon abgeraten, %-ersetzte Zeichen zu verwenden.
[Definition: Ein Namensraum (oder präziser eine Namensraumbindung) wird mit Hilfe reservierter Attribute deklariert. Solch ein Attributname muss entweder xmlns sein oder mit xmlns: beginnen. Diese Attribute, wie alle anderen XML-Attribute, können direkt oder per Voreinstellung übergeben werden.]
[1] | NSAttName | ::= | PrefixedAttName | |
| DefaultAttName | ||||
[2] | PrefixedAttName | ::= | 'xmlns:' NCName |
[NSC: Reservierte Präfixe und Namensraumnamen] |
[3] | DefaultAttName | ::= | 'xmlns' | |
[4] | NCName | ::= | NCNameStartChar
NCNameChar* | /* Ein XML-Name ohne ":" */ |
[5] | NCNameChar | ::= | NameChar
- ':' | |
[5a] | NCNameStartChar | ::= | NameStartChar
- ':' |
Der normalisierte Wert des Attributs MUSS entweder ein IRI-Verweis – der Namensraumname, der den Namensraum identifiziert – oder eine leere Zeichenkette sein. Um seinen beabsichtigten Zweck zu erfüllen, SOLLTE der Namensraumname die Charakteristiken der Einzigartigkeit und der Dauerhaftigkeit besitzen. Sein Ziel ist nicht, dass er direkt für den Empfang eines Schemas verwendet werden kann (sofern eines existiert). Uniform Resource Names [RFC2141] sind ein Beispiel einer Syntax, die mit dieser Absicht im Hinterkopf entwickelt wurde. Es sollte jedoch beachtet werden, dass die Möglichkeit besteht, die gleichen Ziele auch mit normalen URLs zu erreichen.
[Definition: Entspricht der Attributname dem PrefixedAttName, dann gibt der NCName das Namensraum-Präfix an, das dazu verwendet wird, Element- und Attributnamen mit dem Namensraumnamen im Attributwert zu verbinden. Der Attributwert liegt im Geltungsbereich des Elements, an das die Deklaration gebunden ist.]
Kurz, knapp und ungenau:
Der Geltungsbereich des Elements erstreckt sich
über den Inhalt, der zwischen dem öffnenden (<tag>) und dem
schließenden Tag (</tag>) liegt.
Die genaue Definition finden Sie unter 6.1
Geltungsbereich eines Namensraums.
[Definition: Entspricht der Attributname dem DefaultAttName, dann ist der Namensraumname im Attributwert, der des voreingestellten Namensraums im Geltungsbereich des Elements, an das die Deklaration gebunden ist.] Voreingestellte Namensräume und das Überschreiben von Deklarationen wird in 6 Elementen und Attributen Namensräume zuweisen beschrieben.
Ein Beispiel einer Namensraumdeklaration, die das Namensraumpräfix
edi mit dem Namensraumnamen
http://ecommerce.example.org/schema
verbindet:
<x xmlns:edi='http://ecommerce.example.org/schema'> <!-- Das Präfix "edi" ist für das Element x und den Inhalt an http://ecommerce.example.org/schema gebunden --> </x>
Namensraumbeschränkung: Reservierte Präfixe und Namensraumnamen
Das Präfix xml ist per Definition an den Namensraumnamen
http://www.w3.org/XML/1998/namespace
gebunden. Es
KANN, muss
aber nicht deklariert werden und
DARF NICHT
entdeklariert oder an irgendeinen anderen Namensraumnamen gebunden werden.
Andere Präfixe
DÜRFEN
NICHT an diesen Namensraumnamen gebunden werden.
Das Präfix xmlns wird nur zur Deklaration von
Namensraumbindungen verwendet und ist per Definition an den
Namensraumnamen http://www.w3.org/2000/xmlns/
gebunden. Es
DARF NICHT
deklariert oder entdeklariert werden. Andere Präfixe
DÜRFEN
NICHT an diesen Namensraumnamen gebunden werden.
Alle anderen Präfixe, die mit den drei Buchstaben x, m oder l in jeglicher Kombination von Groß- und Kleinschreibung beginnen, sind reserviert. Dies bedeutet, dass:
Benutzer sie NICHT verwenden SOLLTEN, außer es ist in späteren Spezifikationen definiert
Prozessoren sie NICHT als kritische Fehler behandeln DÜRFEN.
Obwohl sie selbst nicht reserviert sind, ist es nicht ratsam, Namen mit
Präfix zu verwenden, deren LocalPart
mit den Buchstaben
x, m oder l in irgendeiner Kombination von Groß- und Kleinschreibung
anfängt, weil diese Namen reserviert wären, wenn sie
ohne Präfix verwendet würden.
In XML-Dokumenten, die konform zu dieser Spezifikation sind, MÜSSEN einige Namen (Konstrukte, die dem Nonterminal Name entsprechen) als qualifizierte Namen angegeben werden, die wie folgt definiert sind:
[6] | QName | ::= | PrefixedName |
| UnprefixedName | |||
[6a] | PrefixedName | ::= |
Prefix ':' LocalPart
|
[6b] | UnprefixedName | ::= |
LocalPart
|
[7] | Prefix | ::= | NCName |
[8] | LocalPart | ::= | NCName |
Das Präfix gibt den Teil des Namensraumpräfix des qualifizierten Namens an und MUSS mit einem Namensraum IRI-Verweis per Namensraumdeklaration verbunden werden. [Definition: Der LocalPart gibt den lokalen Teil des qualifizierten Namens an.]
Beachten Sie, dass das Präfix nur als Platzhalter für einen Namensraumnamen dient. Anwendungen SOLLTEN den Namensraumnamen verwenden, nicht das Präfix, wenn sie Namen erzeugen, die über den Geltungsbereich des enthaltenden Dokuments hinausgehen.
In XML-Dokumenten, die konform zu dieser Spezifikation sind, werden Elementnamen als qualifizierte Namen wie folgt vergeben:
[9] | STag | ::= | '<' QName
(S
Attribute)*
S? '>'
|
[NSC: Präfix deklariert] |
[10] | ETag | ::= | '</' QName
S? '>' |
[NSC: Präfix deklariert] |
[11] | EmptyElemTag | ::= | '<' QName
(S
Attribute)*
S? '/>' |
[NSC: Präfix deklariert] |
Ein Beispiel eines qualifizierten Namens, der als Elementname dient:
<!-- der Namensraum des Elements 'price' ist http://ecommerce.example.org/schema --> <edi:price xmlns:edi='http://ecommerce.example.org/schema' units='Euro'>32.18</edi:price>
Attribute sind entweder Namensraumdeklarationen oder ihre Namen werden als qualifizierte Namen gegeben:
[12] | Attribute | ::= | NSAttName
Eq
AttValue | |
| QName Eq
AttValue |
[NSC: Präfix deklariert] |
Ein Beispiel eines qualifizierten Namens, der als Attributname dient:
<x xmlns:edi='http://ecommerce.example.org/schema'> <!-- der Namensraum des Attributs 'taxClass' ist http://ecommerce.example.org/schema --> <lineItem edi:taxClass="exempt">Baby food</lineItem> </x>
Namensraumbeschränkung: Präfix deklariert
Das Namensraum-Präfix – es sei denn, es ist xml
oder xmlns
–
MUSS in einem
Attribut zur
Namensraumdeklaration
deklariert worden sein. Entweder im Start-Tag des Elements, in dem das
Präfix verwendet wird oder in einem Vorfahren (zum Beispiel in einem
Element, in dessen
Inhalt das mit
Präfix versehene Markup auftaucht).
Des Weiteren
DARF
der Attributwert im Innersten solch einer Deklaration
KEINE
leere Zeichenkette sein.
... im Innersten solch einer Deklaration ...
Möchte einfach nur heißen, der Wert des Attributs
darf keine leere Zeichenkette sein, demnach ist Folgendes NICHT erlaubt:
<edi:price xmlns:edi='' units='Euro'>32.18</edi:price>
Diese Beschränkung kann zu verfahrensbedingten Schwierigkeiten führen, wenn das Namensraum-Deklarationsattribut nicht direkt in der XML-Dokumententität zur Verfügung gestellt wird, sondern über ein voreingestelltes Attribut, das in einer externen Entität deklariert ist. Solche Deklarationen können eventuell nicht von Software gelesen werden, die auf nicht validierenden XML-Prozessoren basiert. Viele XML-Anwendungen, wahrscheinlich ebenfalls Namensraum sensitive, fordern leider keine validierenden Prozessoren. Ist eine korrekte Verarbeitung mit solchen Anwendungen erforderlich, MÜSSEN Namensraum-Deklarationen entweder direkt oder über ein voreingestelltes Attribut im internen Subset der DTD deklariert werden.
Element- und Attributnamen werden ebenfalls als qualifizierte Namen gegeben, wenn sie in Deklarationen in der DTD erscheinen:
[13] | doctypedecl | ::= | '<!DOCTYPE' S
QName (S
ExternalID)?
S? ('['
(markupdecl
| PEReference
| S)*
']'
S?)? '>' |
[14] | elementdecl | ::= | '<!ELEMENT' S
QName
S
contentspec
S? '>' |
[15] | cp | ::= | (QName
| choice
| seq)
('?' | '*' | '+')? |
[16] | Mixed | ::= | '(' S?
'#PCDATA'
(S?
'|'
S?
QName)*
S?
')*' |
| '(' S? '#PCDATA'
S? ')'
| |||
[17] | AttlistDecl | ::= | '<!ATTLIST' S
QName
AttDef*
S? '>' |
[18] | AttDef | ::= | S
(QName | NSAttName)
S
AttType
S
DefaultDecl
|
Beachten Sie, dass die DTD basierte Validierung im folgenden Sinne die
Anforderungen für Namensräume in XML nicht berücksichtigt:
eine DTD beschränkt die Elemente und Attribute,
die in einem Dokument erscheinen können durch ihre uninterpretierten
Namen, nicht durch (Namensraumname, lokaler Name) Paare. Um ein Dokument, das
Namensräume verwendet, gegen eine DTD zu validieren, müssen
die gleichen Präfixe in der DTD wie in der Instanz verwendet werden.
Eine DTD kann jedoch indirekt die Namensräume beschränken,
die in gültigen Dokumenten verwendet werden, und zwar durch die Angabe
von #FIXED
-Werten für Attribute, die Namensräume
deklarieren.
Der Geltungsbereich einer Namensraumdeklaration, die ein Präfix deklariert, reicht vom Anfang des Start-Tags, in dem sie erscheint, bis zum Ende des korrespondierenden End-Tags, ausgeschlossen ist der Geltungsbereich jeglicher innerer Deklarationen mit dem gleichen NSAttName-Teil. Im Fall eines leeren Tags, ist der Geltungsbereich das Tag selbst.
Solch eine Namensraum-Deklaration gilt für alle Element- und Attributnamen innerhalb ihres Geltungsbereichs, deren Präfix dem in der Deklaration angegebenen entspricht.
Der erweiterte Name, der zu einem Element- oder Attributnamen mit Präfix gehört, besitzt den IRI, an den das Präfix gebunden ist als seinen Namensraumnamen, und den lokalen Teil als seinen lokalen Namen.
<?xml version="1.1"?> <html:html xmlns:html='http://www.w3.org/1999/xhtml'> <html:head><html:title>Frobnostication</html:title></html:head> <html:body><html:p>Moved to <html:a href='http://frob.example.com'>here.</html:a></html:p></html:body> </html:html>
Mehrere Namensraumpräfixe können als Attribute eines einzelnen Elements deklariert werden wie im Beispiel unten gezeigt:
<?xml version="1.1"?>
<!-- beide Namensraum-Präfixe sind überall verfügbar -->
<bk:book xmlns:bk='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<bk:title>Cheaper by the Dozen</bk:title>
<isbn:number>1568491379</isbn:number>
</bk:book>
Der Attributwert für ein Präfix in einer Namensraum-Deklaration KANN leer sein. Innerhalb des Geltungsbereichs der Deklaration bewirkt dies, das jede Verbindung des Präfixes mit einem Namensraumnamen entfernt wird. Weitere Deklarationen KÖNNEN das Präfix wieder zurückdeklarieren:
<?xml version="1.1"?>
<x xmlns:n1="http://www.w3.org">
<n1:a/> <!-- gültig; das Präfix ist an http://www.w3.org gebunden -->
<x xmlns:n1="">
<n1:a/> <!-- ungültig; das Präfix n1 ist hier nicht gebunden -->
<x xmlns:n1="http://www.w3.org">
<n1:a/> <!-- gültig; das Präfix n1 ist wieder gebunden -->
</x>
</x>
</x>
Der Geltungsbereich einer voreingestellten Namensraum-Deklaration reicht vom Anfang des Start-Tags, in dem sie angegeben ist, bis ans Ende des korrespondierenden End-Tags, ausgeschlossen ist der Bereich jeglicher innerer voreingestellter Namensraum-Deklarationen. Im Fall eines leeren Tags, ist der Geltungsbereich das Tag selbst.
Eine voreingestellte Namensraum-Deklaration gilt für alle Elementnamen ohne Präfix innerhalb ihres Geltungsbereichs. Voreingestellte Namensraum-Deklarationen gelten nicht direkt für Attributnamen; die Interpretation von Attributen ohne Präfix wird durch das Element bestimmt, in dem sie angegeben sind.
Gibt es eine voreingestellte Namensraumdeklaration im Geltungsbereich, hat der erweiterte Name, der zu einem Elementnamen ohne Präfix gehört, den IRI des voreingestellten Namensraums als seinen Namensraumnamen. Gibt es keine voreingestellte Namensraum-Deklaration, hat der Namensraumname keinen Wert. Der Namensraumname für einen Attributnamen ohne Präfix hat niemals einen Wert. In allen Fällen ist der lokale Name der lokale Teil (welcher natürlich der gleiche ist wie der Name ohne Präfix selbst).
<?xml version="1.1"?> <!-- Elemente sind im HTML-Namensraum, in diesem Fall voreingestellt --> <html xmlns='http://www.w3.org/1999/xhtml'> <head><title>Frobnostication</title></head> <body><p> <a href='http://frob.example.com'>Hierher umgezogen</a>.</p></body> </html>
<?xml version="1.1"?>
<!-- Elementtypen ohne Präfix sind vom Typ "books" -->
<book xmlns='urn:loc.gov:books'
xmlns:isbn='urn:ISBN:0-395-36341-6'>
<title>Günstiger im Dutzend</title>
<isbn:number>1568491379</isbn:number>
</book>
Ein umfangreicheres Beispiel für den Geltungsbereich von Namensräumen:
<?xml version="1.1"?> <!-- Anfangs ist der voreingestellte Namensraum "books" --> <book xmlns='urn:loc.gov:books' xmlns:isbn='urn:ISBN:0-395-36341-6'> <title>Günstiger im Dutzend</title> <isbn:number>1568491379</isbn:number> <notes> <!-- HTML für Kommentare zum voreingestellten Namensraum machen --> <p xmlns='http://www.w3.org/1999/xhtml'> Dies ist ein <i>lustiges</i> Buch! </p> </notes> </book>
Der Attributwert in einer voreingestellten Namensraumdeklaration KANN leer sein. Das bewirkt das gleiche – innerhalb des Geltungsbereichs der Deklaration – als wäre kein voreingestellter Namensraum vorhanden.
<?xml version='1.1'?> <Beers> <!-- der voreingestellte Namensraum innerhalb von Tabellen ist HTML --> <table xmlns='http://www.w3.org/1999/xhtml'> <th><td>Name</td><td>Origin</td><td>Description</td></th> <tr> <!-- kein voreingestellter Namensraum in Tabellenzellen --> <td><brandName xmlns="">Huntsman</brandName></td> <td><origin xmlns="">Bath, UK</origin></td> <td> <details xmlns=""><class>Bitter</class><hop>Fuggles</hop> <pro>Wonderful hop, light alcohol, good summer beer</pro> <con>Fragile; excessive variance pub to pub</con> </details> </td> </tr> </table> </Beers>
In XML-Dokumenten, die konform zu dieser Spezifikation sind, sollte kein Tag zwei Attribute enthalten, die:
identische Namen haben oder
qualifizierte Namen mit gleichem lokalen Teil haben und mit Präfixen, die an identische Namensraumnamen gebunden sind.
Diese Beschränkung ist äquivalent zur Anforderung, dass kein Element zwei Attribute mit dem gleichen erweiterten Namen haben darf.
Zum Beispiel ist im Folgenden keines der Start-Tag bad
gültig:
<!-- http://www.w3.org ist an n1 und n2 gebunden --> <x xmlns:n1="http://www.w3.org" xmlns:n2="http://www.w3.org" > <bad a="1" a="2" /> <bad n1:a="1" n2:a="2" /> </x>
Jedoch ist jedes der folgenden Beispiele gültig, das zweite, weil der voreingestellte Namensraum nicht für Attributnamen gilt:
<!-- http://www.w3.org is bound to n1 and is the default --> <x xmlns:n1="http://www.w3.org" xmlns="http://www.w3.org" > <good a="1" b="2" /> <good a="1" n1:a="2" /> </x>
Diese Spezifikation ist für XML 1.1-Dokumente gültig. Um konform zu dieser Spezifikation zu sein, MUSS ein Dokument entsprechend der Spezifikation XML 1.1 [XML 1.1] wohlgeformt sein.
In XML-Dokumenten, die konform zu dieser Spezifikation sind, MÜSSEN Element- und Attributnamen der Produktion für QName entsprechen und MÜSSEN die Namensraumbeschränkungen erfüllen. Alle anderen Token im Dokument, die der XML-Produktion für Name entsprechen MÜSSEN (um die XML 1.1-Wohlgeformtheit zu erfüllen), MÜSSEN in dieser Spezifikation der Produktion für NCName entsprechen.
[Definition: Ein Dokument ist Namensraum-wohlgeformt, wenn es konform zu dieser Spezifikation ist.]
Es folgt, dass in einem Namensraum-wohlgeformten Dokument:
alle Element- oder Attributnamen entweder keinen oder einen Doppelpunkt enthalten;
weder Entitätnamen, noch Verarbeitungsanweisungsziele oder Notationsnamen irgendwelche Doppelpunkte enthalten.
Zusätzlich sollte ein Namensraum-wohlgeformtes Dokument ebenso Namensraum-gültig sein.
[Definition: Ein Namensraum-wohlgeformtes Dokument ist Namensraum-gültig, wenn es entsprechend der XML 1.1-Spezifikation gültig ist und alle anderen Token – außer den Element- und Attributnamen – die zur XML 1.1-Gültigkeit die XML-Produktion für Name erfüllen MÜSSEN, der Produktion dieser Spezifikation für NCName entsprechen.]
Kurz und knapp.
Elementnamen und Attributnamen sind Token. Es gibt
auch noch andere Token, die in der XML-Spezifikation dem Typ Name
entsprechen müssen, hier aber dem Typ NCName
, um
Namensraum-gültig zu sein.
Es folgt, dass in einem Namensraum-gültigen Dokument:
kein Attribut, das als Typ ID, IDREF(S), ENTITY(IES) oder NOTATION definiert ist, irgendeinen Doppelpunkt enthält.
Um konform zu dieser Spezifikation zu sein, MUSS ein Prozessor Verletzungen der Namenraum-Wohlgeformtheit anzeigen, mit der Ausnahme, dass es nicht ERFORDERLICH ist, zu überprüfen, ob die Namensraumnamen gültige IRIs sind.
[Definition: Ein validierender XML-Prozessor, der Konform zu dieser Spezifikation ist, ist Namensraum-validierend, wenn er zusätzlich Verletzungen der Namensraum-Gültigkeit anzeigt.]
Zur Zeit wird an einem RFC gearbeitet, der Internationalized Resource Identifiers (IRIs) definiert. Weil diese Arbeit noch nicht abgeschlossen ist, gibt dieser Abschnitt eine syntaktische Definition für IRIs, die den Anforderungen dieser Spezifikation genügt. Die XML Core Working Group beabsichtigt, ein Erratum auszugeben, das diesen Abschnitt mit einem Verweis zu dem RFC ersetzt, sobald es veröffentlicht ist.
Benutzern, die Namensräume definieren, wird geraten, Namensraumnamen auf URIs zu beschränken, bis das RFC veröffentlicht ist und Software, die IRIs unterstützt, weitläufig verbreitet ist. Entwicklern wird gleichfalls geraten, keine Namensraumnamen zurückzuweisen, die die Entwürfe in Bezug auf die erlaubten Zeichen verletzen.
Eine allgemeinere Definition und die Diskussion um IRIs finden Sie im [IRI draft 5] (zur Zeit in Arbeit).
URI-Verweise sind auf eine Untermenge der ASCII-Zeichen beschränkt; IRI-Verweise gestatten die meisten Unicode-Zeichen von #xA0 folgend. Frühere Entwürfe des IRI-RFCs (z. Bsp. [IRI draft 3]) gestatteten auch einige der nicht erlaubten ASCII-Zeichen, jedoch ist das im aktuellen Entwurf ([IRI draft 5]) nicht der Fall.
[Definition: Die zusätzlichen Zeichen, die in IRIs laut [IRI draft 5] gestattet sind, lauten:]
Die Unicode-Zeichen der Ebene 0 #xA0 - #xD7FF, #xF900-#xFDCF, #xFDF0-#xFFEF
die Unicode-Zeichen der Ebene 1-14 #x10000-#x1FFFD ... #xD0000-#xDFFFD, #xE1000-#xEFFFD
[Definition: Ein IRI-Verweis ist eine Zeichenkette, die durch folgende Schritte in einen URI-Verweis umgewandelt werden kann:]
Konvertiere den Hostnamen-Teil, sofern gegenwärtig, mit Hilfe der ToASCII-Operation, die in Abschnitt 4.1 des [RFC3490] angegeben ist, mit den Flags UseSTD3ASCIIRules und AllowUnassigned auf TRUE gesetzt.
Ersetze alle zusätzlichen Zeichen wie folgt:
Jedes zusätzliche Zeichen wird als ein oder mehrere Bytes in UTF-8 [RFC3629] konvertiert.
Die resultierenden Bytes werden mit dem URI-Ersatzmechnanismus ersetzt (das bedeutet, konvertiert in %HH, wobei HH die hexadezimale Schreibweise des Byte-Werts ist).
Das originale Zeichen wird durch die resultierende Zeichensequenz ersetzt.
Anmerkung:
Der Algorithmus in [IRI draft 5] schließt einen UCS-Normalisierungsschritt ein, aber das macht bei Zeichenketten, die IRI-Verweise sind, keinen Unterschied.
Der angesprochene Entwurf liegt zur Zeit der Fertigstellung der Übersetzung in Version 11 vor. Einen aktuellen Überblick finden sie hier: http://www.w3.org/International/iri-edit/.
Diese Version nimmt die Errata zur Version 1.0 bis zum 6. Dezember 2002 auf [1.0 Errata]. Es gibt zwei weitere wichtige Änderungen:
Ein Mechanismus zur Entdeklarierung von Präfixen wird gegeben;
Namensraumnamen sind IRIs statt URIs.
Es gibt einige redaktionelle Änderungen, einschließlich einiger Änderungen der Terminologie und Zusätze, die bessere Konsistenz erzeugen sollen. Der nicht normative Anhang Die interne Struktur von XML-Namensräume wurde entfernt.
Diese Arbeit spiegelt die Leistungen sehr vieler Leute wider, besonders der Mitglieder der World Wide Web Consortium XML Working Group und der Special Interest Group und den Mitgliedern der W3C Metadata Activity. Die Beiträge von Charles Frankston von Microsoft waren besonders wertvoll.