Uniform Resource Identifier

Ein Uniform Resource Identifier ( URI ), früher Universal Resource Identifier , ist eine eindeutige Zeichenfolge, die eine abstrakte oder physische Ressource identifiziert, ^{[ 1 ] :1} wie beispielsweise Ressourcen auf einer Webseite , eine E-Mail-Adresse , eine Telefonnummer, ^{[ 1 ] :7} Bücher, reale Objekte wie Personen und Orte sowie Konzepte. Die Ressource muss insbesondere nicht über das Internet oder ein anderes Computernetzwerk abrufbar sein. ^{[ 1 ] :5}

URIs, die das Auffinden und Abrufen von Informationsressourcen in einem Netzwerk (wie dem Internet , einem Intranet oder einem Dateisystem ) ermöglichen, werden als Uniform Resource Locators (URLs) bezeichnet. URLs sind somit eine Teilmenge der URIs. ^{[ 1 ] : 7} Andere URIs liefern lediglich einen eindeutigen Namen, ohne die Möglichkeit, die Ressource oder Informationen darüber aufzufinden oder abzurufen; diese werden als Uniform Resource Names (URNs) bezeichnet. Die Webtechnologien, die URIs verwenden, beschränken sich nicht auf Webbrowser .

URIs und URLs haben eine gemeinsame Geschichte. 1990 führte Tim Berners-Lee mit seinen Hypertext- Vorschlägen implizit die Idee einer URL als kurze Zeichenkette ein, die eine Ressource repräsentiert, auf die ein Hyperlink verweist . ^{[ 2 ]} Damals sprach man von einem „Hypertextnamen“ ^{[ 3 ]} oder „Dokumentnamen“.

In den folgenden dreieinhalb Jahren, mit der Entwicklung der Kerntechnologien des World Wide Web – HTML , HTTP und Webbrowser – , entstand der Bedarf, zwischen einer Adresse für eine Ressource und einer bloßen Ressourcenbezeichnung zu unterscheiden. Obwohl noch nicht formal definiert, setzte sich der Begriff „Uniform Resource Locator“ für Ersteres und der umstrittenere „Uniform Resource Name“ für Letzteres durch. Im Juli 1992 erwähnte Berners-Lee in seinem Bericht zur „UDI (Universal Document Identifiers) BOF “ der Internet Engineering Task Force (IETF) URLs (als Uniform Resource Locators), URNs (ursprünglich „Unique Resource Numbers“) und die Notwendigkeit, eine neue Arbeitsgruppe einzurichten. ^{[ 4 ]} Im November 1992 trat die IETF-Arbeitsgruppe „URI“ erstmals zusammen. ^{[ 5 ]}

Im Zuge der Debatte um die Definition von URLs und URNs wurde deutlich, dass die beiden Begriffe lediglich Aspekte des grundlegenden, übergeordneten Konzepts der Ressourcenidentifizierung darstellen . Im Juni 1994 veröffentlichte die IETF RFC 1630 , Berners-Lees erste Request for Comments , in der die Existenz von URLs und URNs anerkannt wurde. Vor allem definierte sie eine formale Syntax für universelle Ressourcenkennungen (d. h. URL-ähnliche Zeichenketten, deren genaue Syntax und Semantik von ihren Schemata abhingen). Außerdem versuchte sie, die damals gebräuchlichen Syntaxen von URL-Schemata zusammenzufassen. Sie erkannte die Existenz relativer URLs und Fragmentbezeichner an, standardisierte sie aber nicht . ^{[ 6 ]} 

Im Dezember 1994 definierte RFC  1738 ^{[ 7 ]} relative und absolute URLs formal, verfeinerte die allgemeine URL-Syntax, legte fest, wie relative URLs in absolute URLs umgewandelt werden, und listete die damals gebräuchlichen URL-Schemata genauer auf. Die vereinbarte Definition und Syntax von URNs musste bis zur Veröffentlichung von IETF RFC  2141 ^{[ 8 ]} im Mai 1997 warten .

Mit der Veröffentlichung des IETF RFC 2396 ^{[ 9 ]} im August 1998 wurde die URI-Syntax zu einer eigenständigen Spezifikation ^{[ 9 ],} und die meisten Teile der RFCs 1630 und 1738, die sich allgemein auf URIs und URLs bezogen, wurden von der IETF überarbeitet und erweitert. Der neue RFC änderte die Bedeutung des „ U“ in URI von „Universal“ zu „Uniform“.  

Im Dezember 1999 enthielt RFC  2732 ^{[ 10 ]} eine kleinere Aktualisierung von RFC 2396, die es ermöglichte, IPv6 -Adressen in URIs zu verwenden. Aufgrund einiger in den beiden Spezifikationen festgestellter Mängel wurde eine Gemeinschaftsinitiative unter der Leitung von Roy Fielding , einem der Mitautoren von RFC 2396, ins Leben gerufen, die im Januar 2005 zur Veröffentlichung von IETF RFC  3986 ^{[ 1 ]} führte . Obwohl der vorherige Standard dadurch ersetzt wurde, blieben die Details bestehender URL-Schemata erhalten; RFC 1738 regelt diese weiterhin, sofern nicht anderweitig ersetzt. IETF RFC  2616 ^{[ 11 ]} beispielsweise verfeinert das httpSchema. Gleichzeitig veröffentlichte die IETF den Inhalt von RFC 3986 als vollständigen Standard STD 66 und etablierte damit die generische URI-Syntax als offizielles Internetprotokoll.

Im Jahr 2001 veröffentlichte die Technical Architecture Group (TAG) des World Wide Web Consortiums (W3C) einen Leitfaden mit Best Practices und kanonischen URIs für die Veröffentlichung mehrerer Versionen einer Ressource. ^{[ 12 ]} Inhalte können sich beispielsweise in Sprache oder Größe unterscheiden, um die Kapazität oder die Einstellungen des verwendeten Endgeräts zu berücksichtigen.

Im August 2002 wies die IETF in RFC 3305 ^{[ 13 ]} darauf hin, dass der Begriff „URL“ trotz seiner weitverbreiteten öffentlichen Verwendung nahezu obsolet geworden sei und lediglich daran erinnere, dass manche URIs als Adressen fungieren, indem sie Schemata verwenden, die Netzwerkzugänglichkeit implizieren – unabhängig von einer tatsächlichen Nutzung. Wie URI-basierte Standards wie das Resource Description Framework (RDF) verdeutlichen, muss die Ressourcenidentifizierung weder den Abruf von Ressourcendarstellungen über das Internet implizieren, noch muss sie überhaupt netzwerkbasierte Ressourcen implizieren.  

Das semantische Web verwendet das HTTP-URI-Schema, um sowohl Dokumente als auch Konzepte für praktische Zwecke zu identifizieren. Diese Unterscheidung führte zu Verwirrung hinsichtlich der korrekten Abgrenzung der beiden. Die TAG veröffentlichte 2005 eine E-Mail mit einer Lösung für dieses Problem, die als httpRange-14-Resolution bekannt wurde . ^{[ 14 ]} Das W3C veröffentlichte anschließend eine Interest Group Note mit dem Titel „Cool URIs for the Semantic Web“, in der die Verwendung von Content Negotiation und des HTTP-Antwortcodes 303 für Weiterleitungen detaillierter erläutert wurde. ^{[ 15 ]}

Ein Uniform Resource Name (URN) ist ein URI, der eine Ressource in einem bestimmten Namensraum anhand ihres Namens identifiziert. Ein URN kann verwendet werden, um über eine Ressource zu sprechen, ohne deren Speicherort oder Zugriffsmöglichkeit preiszugeben. Beispielsweise identifiziert im System der Internationalen Standardbuchnummern (ISBN) die ISBN 0-486-27557-4 eine bestimmte Ausgabe von William Shakespeares Drama „Romeo und Julia“ . Der URN für diese Ausgabe lautet urn:isbn:0-486-27557-4 . Er gibt jedoch keine Auskunft darüber, wo man ein Exemplar dieses Buches finden kann.

Ein Uniform Resource Locator (URL) ist ein URI, der die Art und Weise des Zugriffs auf eine Ressource oder deren Darstellung angibt, d. h. sowohl den primären Zugriffsmechanismus als auch den Netzwerkstandort. Beispielsweise http://example.org/wiki/Main_Pageverweist die URL auf eine Ressource mit der Kennung /wiki/Main_Page, deren Darstellung über das Hypertext Transfer Protocol ( HTTP ) von einem Netzwerkhost mit dem Domainnamen abgerufenexample.org werden kann . (HTTP impliziert in diesem Fall üblicherweise HTML -Code. In der Praxis ist dies jedoch nicht zwingend der Fall, da HTTP die Angabe beliebiger Formate im Header ermöglicht.)

Eine URN ist vergleichbar mit dem Namen einer Person, während eine URL ihrer Adresse entspricht. Anders ausgedrückt: Eine URN identifiziert ein Objekt, und eine URL bietet eine Methode, um es zu finden.

Technische Veröffentlichungen, insbesondere Standards, die von der IETF und dem W3C erstellt werden, spiegeln in der Regel die in einer W3C-Empfehlung vom 30. Juli 2001 dargelegte Ansicht wider, die den Vorrang des Begriffs URI anerkennt, anstatt eine formale Unterteilung in URL und URN zu befürworten.

Die URL ist ein nützliches, aber informelles Konzept: Eine URL ist eine Art URI, die eine Ressource über eine Darstellung ihres primären Zugriffsmechanismus (z. B. ihres Netzwerk-"Standorts") identifiziert, anstatt über andere Attribute, die sie möglicherweise besitzt. ^{[ 16 ]}

Eine URL ist demnach einfach ein URI, der auf eine Ressource in einem Netzwerk verweist. ^{[ a ] ​​[ 13 ]} Im nicht-technischen Kontext und in Software für das World Wide Web ist der Begriff „URL“ jedoch weiterhin weit verbreitet. Auch der Begriff „Webadresse“ (für den es keine formale Definition gibt) wird in nicht-technischen Publikationen oft synonym für einen URI verwendet, der die http- oder https -Schemas nutzt. Solche Annahmen können zu Verwirrung führen, beispielsweise bei XML-Namensräumen, die eine visuelle Ähnlichkeit mit auflösbaren URIs aufweisen .

Die von der WHATWG erstellten Spezifikationen bevorzugen URLs gegenüber URIs , daher verwenden neuere HTML5-APIs URLs anstelle von URIs . ^{[ 17 ]}

Standardisieren Sie sich auf den Begriff URL. URI und IRI (Internationalized Resource Identifier) ​​sind verwirrend. In der Praxis wird für beide derselbe Algorithmus verwendet, daher bringt die Unterscheidung nichts. URLs erzielen zudem deutlich höhere Suchergebnisse. ^{[ 18 ]}

Obwohl die meisten URI-Schemata ursprünglich für die Verwendung mit einem bestimmten Protokoll entwickelt wurden und oft denselben Namen tragen, unterscheiden sie sich semantisch von Protokollen. Beispielsweise wird das Schema http im Allgemeinen für die Interaktion mit Webressourcen über HTTP verwendet , das Schema file hat jedoch kein eigenes Protokoll.

Ein URI besitzt ein Schema, das eine Spezifikation für die Zuweisung von Bezeichnern innerhalb dieses Schemas definiert. Die URI-Syntax ist somit ein föderiertes und erweiterbares Namenssystem, in dem die Spezifikation jedes Schemas die Syntax und Semantik der Bezeichner, die dieses Schema verwenden, weiter einschränken kann. Die generische URI-Syntax ist eine Obermenge der Syntax aller URI-Schemata. Sie wurde erstmals in RFC 2396 (veröffentlicht im August 1998) ^{[ 9 ]} definiert und in RFC 3986 (veröffentlicht im Januar 2005) ^{[ 19 ] finalisiert.}  

Ein URI setzt sich aus einer zulässigen Menge von ASCII- Zeichen zusammen, bestehend aus reservierten Zeichen (generische Trennzeichen: :, /, ?, #, [, ], und @; Untertrennzeichen: !, $, &, ', (, ), *, +, ,, ;, und =), ^{[ 1 ] : 13–14} nicht reservierten Zeichen ( Groß- und Kleinbuchstaben , Dezimalziffern , -, ., _, und ~), ^{[ 1 ] : 13–14} und dem Zeichen %. ^{[ 1 ] : 12.} Syntaxkomponenten und Unterkomponenten werden durch Trennzeichen von den reservierten Zeichen (bei Komponenten nur von generischen reservierten Zeichen) getrennt und definieren Identifikationsdaten, die als nicht reservierte Zeichen, reservierte Zeichen, die in der Komponente bzw. Unterkomponente nicht als Trennzeichen fungieren, ^{[ 1 ] : §2} und Prozentkodierungen dargestellt werden, wenn das entsprechende Zeichen außerhalb der zulässigen Menge liegt oder als Trennzeichen der Komponente oder innerhalb der Komponente verwendet wird. Die Prozentkodierung eines Identifikationsdatenoktetts ist eine Folge von drei Zeichen, bestehend aus dem Zeichen %gefolgt von den beiden Hexadezimalziffern, die den numerischen Wert dieses Oktetts darstellen. ^{[ 1 ] : §2.1}

Die generische URI-Syntax besteht aus fünf Komponenten, die hierarchisch in absteigender Reihenfolge ihrer Bedeutung von links nach rechts angeordnet sind: ^{[ 1 ] : §3}

URI = Schema ":" ["//" Autorität] Pfad ["?" Abfrage] ["#" Fragment] 

Eine Komponente ist undefiniert, wenn ihr ein Trennzeichen zugeordnet ist und dieses Trennzeichen nicht im URI vorkommt; die Schema- und Pfadkomponenten sind immer definiert. ^{[ 1 ] : §5.2.1} Eine Komponente ist leer , wenn sie keine Zeichen enthält; die Schemakomponente ist immer nicht leer. ^{[ 1 ] : §3}

Die Autoritätskomponente besteht aus Unterkomponenten :

Autorität = [userinfo "@"] Host [":" Port] 

Dies wird in einem Syntaxdiagramm wie folgt dargestellt:

Die URI umfasst:

• Ein nicht leererEin Schema besteht:aus einer Zeichenfolge, die mit einem Buchstaben beginnt und von einer beliebigen Kombination aus Buchstaben, Ziffern, Pluszeichen (+), Punkt (.) oder Bindestrich (-) gefolgt wird. Obwohl Schemata nicht zwischen Groß- und Kleinschreibung unterscheiden, ist die kanonische Form kleingeschrieben, und Dokumente, die Schemata angeben, müssen dies in Kleinbuchstaben tun. Beispiele für gängige Schemata sindhttp,https,ftp,mailto,file,dataundInternet Assigned Numbers Authority (IANA)ircregistriert werden, obwohl in der Praxis auch nicht registrierte Schemata verwendet werden. ^{[ 20 ]}
• Eine optionaleBerechtigungskomponente , der zwei Schrägstriche (//) vorangestellt sind, bestehend aus:
  • Eine optionaleDie Benutzerinformationskomponente , gefolgt von einem @-Zeichen (@), kann aus einemBenutzernamenund einem optionalenPasswort, dem ein Doppelpunkt (:) vorangestellt ist. Die Verwendung dieses Formatsusername:passwordin der Benutzerinformationskomponente ist aus Sicherheitsgründen veraltet. Anwendungen sollten Daten nach dem ersten Doppelpunkt ( ) innerhalb einer Benutzerinformationskomponente nicht im Klartext ausgeben,:es sei denn, die Daten nach dem Doppelpunkt sind eine leere Zeichenkette (was bedeutet, dass kein Passwort vorhanden ist).
  • ADie Host- Subkomponente besteht entweder aus einem registrierten Namen (einschließlich, aber nicht beschränkt auf einenHostnamen) oder einerIP-Adresse.IPv4-Adressen müssen inPunktdezimalschreibweise angegeben, undIPv6-Adressen müssen in eckige Klammern gesetzt werden[]. ^{[ 1 ] : §3.2.2 [ b ]}
  • Eine optionalePort- Subkomponente, der ein Doppelpunkt (:) vorangestellt ist und die aus Dezimalziffern besteht.
• ADie Pfadkomponente besteht aus einer Folge von Pfadsegmenten, die durch Schrägstriche (\/) getrennt sind. Für einen URI ist immer ein Pfad definiert, der jedoch leer (Länge null) sein kann. Auch ein Segment kann leer sein, was zu zwei aufeinanderfolgenden Schrägstrichen (\//) in der Pfadkomponente führt. Eine Pfadkomponente kann einemDateisystempfad, impliziert aber nicht zwangsläufig eine Beziehung zu einem solchen. Ist eine Berechtigungskomponente definiert, muss die Pfadkomponente entweder leer sein oder mit einem Schrägstrich (\/) beginnen. Ist keine Berechtigungskomponente definiert, darf der Pfad nicht mit einem leeren Segment – ​​also mit zwei Schrägstrichen (\//) – beginnen, da die folgenden Zeichen als Berechtigungskomponente interpretiert würden. ^{[ 9 ] : §3.3}

Konventionsgemäß wird bei http- und https- URIs der letzte Teil eines Pfades als benanntDie Angabe von PATH_INFO ist optional. Sie besteht aus null oder mehr Pfadsegmenten, die nicht auf einen vorhandenen physischen Ressourcennamen (z. B. eine Datei, ein internes Modulprogramm oder ein ausführbares Programm) verweisen, sondern auf einen logischen Teil (z. B. einen Befehl oder einen Qualifikator), der separat an den ersten Teil des Pfades übergeben werden muss, der ein vomWebserver. Dies wird häufig verwendet, um dynamische Inhalte (ein Dokument usw.) auszuwählen oder sie nach Bedarf anzupassen (siehe auch:CGIund PATH_INFO usw.).

Beispiel:

URI:"http://www.example.com/questions/3456/my-document"

wobei: "/questions"der erste Teil des Pfades (ein ausführbares Modul oder Programm) und "/3456/my-document"der zweite Teil des Pfades mit dem Namen pathinfo ist , der an das ausführbare Modul oder Programm mit dem Namen übergeben wird, "/questions"um das angeforderte Dokument auszuwählen.

Eine http- oder https- URI, die einen Pfadinformationsteil ohne Abfrageteil enthält , kann auch als „ saubere URL “ bezeichnet werden, deren letzter Teil ein „ Slug “ sein kann.

• Eine optionaleDie Abfragekomponente , der ein Fragezeichen vorangestellt ist (?), besteht aus einerAbfragezeichenfolgenicht-hierarchischer Daten. Ihre Syntax ist nicht genau definiert, besteht aber üblicherweise aus einer Folge vonAttribut-Wert-Paaren,die durch einTrennzeichen.
• Eine optionaleEin Fragment, dem einHash(##) vorangestellt ist, enthält eineFragmentkennung,die auf eine sekundäre Ressource verweist, beispielsweise auf eine Abschnittsüberschrift in einem Artikel, die durch den Rest der URI identifiziert wird. Handelt es sich bei der primären Ressource um einHTML-Dokument, ist das Fragment häufig einidAttributeines bestimmten Elements, und Webbrowser scrollen dieses Element in den sichtbaren Bereich.

Das schema- oder implementierungsspezifische reservierte Zeichen +kann in Schema, Benutzerinformationen, Host, Pfad, Abfrage und Fragment verwendet werden. Die schema- oder implementierungsspezifischen reservierten Zeichen !, $, &, ', (, ), *, ,, ;, und =können in Benutzerinformationen, Host, Pfad, Abfrage und Fragment verwendet werden. Zusätzlich :kann das generische reservierte Zeichen in Benutzerinformationen, Pfad, Abfrage und Fragment verwendet werden. Die generischen reservierten Zeichen @und /können in Pfad, Abfrage und Fragment verwendet werden. Das generische reservierte Zeichen ?kann in Abfrage und Fragment verwendet werden. ^{[ 1 ] : §A}

Die folgende Abbildung zeigt Beispiel-URIs und ihre Bestandteile.

DOIs ( Digital Object Identifiers ) passen in das Handle-System und in das URI-System, was durch eine geeignete Syntax ermöglicht wird .

Eine URI-Referenz ist entweder eine URI oder eine relative Referenz, wenn sie nicht mit einer Schemakomponente gefolgt von einem Doppelpunkt ( :) beginnt. ^{[ 1 ] : §4.1} Ein Pfadsegment, das einen Doppelpunkt enthält (z. B. foo:bar), kann nicht als erstes Pfadsegment einer relativen Referenz verwendet werden, wenn seine Pfadkomponente nicht mit einem Schrägstrich ( /) beginnt, da es sonst fälschlicherweise als Schemakomponente interpretiert würde. Einem solchen Pfadsegment muss ein Punktpfadsegment vorangestellt werden (z. B. ./foo:bar). ^{[ 1 ] : §4.2}

Webdokument- Auszeichnungssprachen verwenden häufig URI-Referenzen, um auf andere Ressourcen zu verweisen, wie z. B. externe Dokumente oder bestimmte Abschnitte desselben logischen Dokuments: ^{[ 1 ] : §4.4}

• In HTML liefert der Wert des srcAttributs des imgElements eine URI-Referenz, ebenso wie der Wert des hrefAttributs des aoder link-Elements;
• In XML ist der Systembezeichner , der nach dem SYSTEMSchlüsselwort in einer DTD erscheint , eine fragmentlose URI-Referenz;
• In XSLT ist der Wert des hrefAttributs des xsl:importElements/der Anweisung eine URI-Referenz; ebenso das erste Argument der document()Funktion.

https://example.com/path/resource.txt#fragment //example.com/path/resource.txt /Pfad/resource.txt Pfad/resource.txt ../resource.txt ./resource.txt resource.txt #Fragment 

Die Auflösung einer URI-Referenz anhand einer Basis-URI ergibt eine Ziel-URI . Dies impliziert, dass die Basis-URI existiert und eine absolute URI ist (eine URI ohne Fragmentkomponente). Die Basis-URI kann in der Reihenfolge ihrer Priorität aus ^{[ 1 ] : §5.1} ermittelt werden.

• die Referenz-URI selbst, falls es sich um eine URI handelt;
• der Inhalt der Darstellung;
• die Entität, die die Repräsentation umschließt;
• Die URI, die für den eigentlichen Abruf der Repräsentation verwendet wird;
• der Kontext der Anwendung.

Innerhalb einer Repräsentation mit einer wohldefinierten Basis-URI von

http://a/b/c/d;p?q 

Ein relativer Verweis wird wie folgt in seinen Ziel-URI aufgelöst: ^{[ 1 ] : §5.4}

"g:h" -> "g:h" "g" -> "http://a/b/c/g" "./g" -> "http://a/b/c/g" "g/" -> "http://a/b/c/g/" "/g" -> "http://a/g" "//g" -> "http://g" "?y" -> "http://a/b/c/d;p?y" "g?y" -> "http://a/b/c/g?y" "#s" -> "http://a/b/c/d;p?q#s" "g#s" -> "http://a/b/c/g#s" "g?y#s" -> "http://a/b/c/g?y#s" ";x" -> "http://a/b/c/;x" "g;x" -> "http://a/b/c/g;x" "g;x?y#s" -> "http://a/b/c/g;x?y#s" "" -> "http://a/b/c/d;p?q" "." -> "http://a/b/c/" "./" -> "http://a/b/c/" ".." -> "http://a/b/" "../" -> "http://a/b/" "../g" -> "http://a/b/g" "../." -> "http://a/" "../../" -> "http://a/" "../../g" -> "http://a/g" 

URL-Munging ist eine Technik, bei der ein Befehl an eine URL angehängt wird, üblicherweise am Ende nach einem „?“- Token . Sie wird häufig in WebDAV verwendet , um HTTP um zusätzliche Funktionen zu erweitern . In einem Versionsverwaltungssystem wird beispielsweise der Befehl „checkout“ wie folgt an eine URL angehängt: http://editing.com/resource/file.php?command=checkout. Dies hat den Vorteil, dass es sowohl für CGI-Parser einfach zu handhaben ist als auch als Vermittler zwischen HTTP und der zugrunde liegenden Ressource dient. ^{[ 24 ]}

In XML ist ein Namensraum eine abstrakte Domäne, der eine Sammlung von Element- und Attributnamen zugewiesen werden kann. Der Namensraumname ist eine Zeichenkette, die der generischen URI-Syntax entsprechen muss. ^{[ 25 ]} Allerdings wird der Name im Allgemeinen nicht als URI betrachtet, ^{[ 26 ]} da die URI-Spezifikation die Entscheidung nicht nur auf lexikalischen Komponenten, sondern auch auf deren beabsichtigter Verwendung basiert. Ein Namensraumname impliziert nicht notwendigerweise die Semantik von URI-Schemata; beispielsweise muss ein Namensraumname, der mit http: beginnt , keine Konnotation zur Verwendung von HTTP haben .

Ursprünglich konnte der Namespace-Name der Syntax einer beliebigen nicht leeren URI-Referenz entsprechen, die Verwendung relativer URI-Referenzen wurde jedoch vom W3C als veraltet eingestuft. ^{[ 27 ]} Eine separate W3C-Spezifikation für Namespaces in XML 1.1 erlaubt neben URI-Referenzen auch die Verwendung von Internationalized Resource Identifier (IRI)-Referenzen als Grundlage für Namespace-Namen. ^{[ 28 ]}

• CURIE
• Verknüpfte Daten
• Erweiterbarer Ressourcenbezeichner
• Internationalisierter Ressourcenidentifikator (IRI)
• Internet-Ressourcen-Locator
• Persistenter Uniform Resource Locator
• Einheitliche Namenskonvention
• Beschreibungssprache für Ressourcenverzeichnisse
• Universell eindeutiger Bezeichner
• Liste der URI-Schemata
• Rahmenwerk zur Ressourcenbeschreibung

• Bray, Tim ; Hollander, Dave; Layman, Andrew; Tobin, Richard (Hrsg.). (16.08.2006). „Namespaces in XML 1.1 (Zweite Auflage)“ . World Wide Web Consortium . 2.2 Verwendung von URIs als Namespace-Namen . Abgerufen am 31.08.2015 .
• Bray, Tim ; Hollander, Dave; Layman, Andrew; Tobin, Richard; Thompson, Henry S. (Hrsg.). (08.12.2009). „Namespaces in XML 1.0 (Dritte Auflage)“ . World Wide Web Consortium . 2.2 Verwendung von URIs als Namespace-Namen . Abgerufen am 31.08.2015 .
• Harold, Elliotte Rusty (2004). XML 1.1 Bibel (3. Aufl.). Wiley Publishing . S. 291. ISBN 978-0-7645-4986-1Die
• Lawrence, Eric (06.03.2014). „Browser Arcana: IP Literals in URLs“ . IEInternals . Microsoft . Abgerufen am 25.04.2016 .
• Morrison, Michael Wayne (2006). „Stunde 5: Namensräume in der Praxis “. Sams Teach Yourself XML . Sams Publishing . S. 91.
• Whitehead, EJ (1998). „WebDAV: IEFT-Standard für kollaboratives Schreiben im Web“. IEEE Internet Computing . 2 (5): 34–40 . doi : 10.1109/4236.722228 . ISSN  1941-0131 .

• URI-Schemas  – von der IANA geführtes Register der URI-Schemas
• URI-Schemata im W3C-Wiki
• Architektur des World Wide Web, Band 1, §2: Identifizierung  – vom W3C
• W3C-URI-Klarstellung