Namensräume in XML 1.1 - W3C-Empfehlung vom 04. Februar 2004

Deutsche Übersetzung

31. Januar 2005

Diese Version:

http://www.schumacher-netz.de/TR/2004/REC-xml-names11-20040204-de.html

Übersetzer:

Stefan Schumacher, schumacher-netz.de <sts@schumacher-netz.de>

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.

W3C

Namenräume in XML 1.1

W3C-Empfehlung vom 4. Februar 2004

Diese Version:
http://www.w3.org/TR/2004/REC-xml-names11-20040204
Aktuelle Version:
http://www.w3.org/TR/xml-names11
Vorherige Version:
http://www.w3.org/TR/2003/PR-xml-names11-20031105
Editoren:
Tim Bray, Textuality <tbray@textuality.com>
Dave Hollander, Contivo, Inc. <dmh@contivo.com>
Andrew Layman, Microsoft <andrewl@microsoft.com>
Richard Tobin, University of Edinburgh und Markup Technology Ltd <richard@cogsci.ed.ac.uk> - Version 1.1

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.


Zusammenfassung

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.

Status dieses Dokuments

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 xml-names-editor@w3.org; ö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.

Inhaltsverzeichnis

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)

Anhänge

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)


1 Motivation und Zusammenfassung

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.

1.1 Anmerkung zur Schreibweise und Verwendung

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.

Kommentar des Übersetzers

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.

2 XML-Namensräume

2.1 Grundlegende Konzepte

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

2.2 Verwendung von IRIs als Namensraum-Namen

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

2.3 IRI-Verweise vergleichen

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:

Die folgenden IRI-Verweise sind ebenfalls verschieden, wenn es um die Identifikation von Namensräumen geht:

So auch diese:

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.

Da ein Verwechslungsrisiko zwischen IRIs besteht, die nach der Dereferenzierung gleich sind, wird in Namensraumnamen dringend davon abgeraten, %-ersetzte Zeichen zu verwenden.

3 Namensräume deklarieren

[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.]

Attributnamen für die Namensraumdeklaration
[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.]

Kommentar des Übersetzers

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.

4 Qualifizierte Namen

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:

Qualifizierter Name (Qualified Name)
[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.

5 Qualifizierte Namen verwenden

In XML-Dokumenten, die konform zu dieser Spezifikation sind, werden Elementnamen als qualifizierte Namen wie folgt vergeben:

Elementnamen
[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:

Attribute
[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 xmlnsMUSS 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.

Kommentar des Übersetzers

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

Qualifizierte Namen in Deklarationen
[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.

6 Elementen und Attributen Namensräume zuweisen

6.1 Geltungsbereich eines Namensraums

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>

6.2 Voreingestellte Namensräume

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>

6.3 Einzigartigkeit von Attributen

In XML-Dokumenten, die konform zu dieser Spezifikation sind, sollte kein Tag zwei Attribute enthalten, die:

  1. identische Namen haben oder

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

7 Konformität von Dokumenten

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:

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

Kommentar des Übersetzters

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:

8 Konformität von Prozessoren

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

9 Internationalized Resource Identifiers (IRIs)

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

[Definition: Ein IRI-Verweis ist eine Zeichenkette, die durch folgende Schritte in einen URI-Verweis umgewandelt werden kann:]

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

  2. Ersetze alle zusätzlichen Zeichen wie folgt:

    1. Jedes zusätzliche Zeichen wird als ein oder mehrere Bytes in UTF-8 [RFC3629] konvertiert.

    2. Die resultierenden Bytes werden mit dem URI-Ersatzmechnanismus ersetzt (das bedeutet, konvertiert in %HH, wobei HH die hexadezimale Schreibweise des Byte-Werts ist).

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

Kommentar des Übersetzers

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

A Normative Quellen

Keywords
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, ed. IETF (Internet Engineering Task Force), March 1997. Available at http://www.rfc-editor.org/rfc/rfc2119.txt
RFC2141
RFC 2141: URN Syntax, R. Moats, ed. IETF (Internet Engineering Task Force), May 1997. Available at http://www.rfc-editor.org/rfc/rfc2141.txt.
RFC2396
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, and L. Masinter, eds. IETF (Internet Engineering Task Force), August 1998. Available at http://www.rfc-editor.org/rfc/rfc2396.txt
RFC2732
RFC 2732: Format for Literal IPv6 Addresses in URL's, R. Hinden, B. Carpenter, and L. Masinter, eds. IETF (Internet Engineering Task Force), December 1999. Available at http://www.rfc-editor.org/rfc/rfc2732.txt.
RFC3490
RFC 3490: Internationalizing Domain Names in Applications (IDNA), P. Faltstrom, P. Hoffman, and A. Costello, eds. IETF (Internet Engineering Task Force), March 2003. Available at http://www.rfc-editor.org/rfc/rfc3490.txt
RFC3629
RFC 3629: UTF-8, a transformation format of ISO 10646, F. Yergeau, ed. IETF (Internet Engineering Task Force), November 2003. Available at http://www.rfc-editor.org/rfc/rfc3629.txt
XML
Extensible Markup Language (XML) 1.0 (Third Edition), Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and François Yergeau eds. W3C (World Wide Web Consortium), 4 February 2004. Available at http://www.w3.org/TR/REC-xml.
XML 1.1
Extensible Markup Language (XML) 1.1, Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, and John Cowan eds. W3C (World Wide Web Consortium), 4 February 2004. Available at http://www.w3.org/TR/xml11.

B Andere Quellen (nicht normativ)

IRI draft 3
Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard eds. March 2, 2003. Available at http://www.w3.org/International/iri-edit/draft-duerst-iri-03.txt.
IRI draft 5
Internationalized Resource Identifiers (IRIs), M. Duerst and M. Suignard eds. October 26, 2003. Available at http://www.w3.org/International/iri-edit/draft-duerst-iri-05.txt.
1.0 Errata
Namespaces in XML Errata. W3C (World Wide Web Consortium). Available at http://www.w3.org/XML/xml-names-19990114-errata.
Relative URI deprecation
Results of W3C XML Plenary Ballot on relative URI References In namespace declarations 3-17 July 2000, Dave Hollander and C. M. Sperberg-McQueen, 6 September 2000. Available at http://www.w3.org/2000/09/xppa.
Requirements
Namespaces in XML 1.1 Requirements, Jonathan Marsh, ed. W3C (World Wide Web Consortium), March 2002. Available at http://www.w3.org/TR/2002/WD-xml-names11-req-20020403/.

C Die interne Struktur von XML-Namensräume (Nicht Normativ)

Dieser Abschnitt wurde gelöscht.

D Änderungen seit Version 1.0 (Nicht Normativ)

Diese Version nimmt die Errata zur Version 1.0 bis zum 6. Dezember 2002 auf [1.0 Errata]. Es gibt zwei weitere wichtige Änderungen:

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.

E Danksagungen (Nicht Normativ)

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.