Zusammenfassung

  • RFC 3151 normalisierte eine Public-Identifier-Zeichenfolge und transkribierte Leerraum, Strukturtrenner und reservierte Literale deterministisch als urn:publicid:; eine richtige Umwandlung validierte weder Eigentümer noch Ressource.
  • Lexikalische Gleichheit blieb eng: Nach der Normalisierung waren zwei URNs nur bei Zeichenidentität äquivalent. Gleiche Namen konnten dennoch unterschiedliche Kataloge, Bytes und Wirkungen treffen.
  • Auflösung blieb mit Katalog, lokalem Pfad, eingebautem Wissen oder Cache kontextabhängig; Auswahl, Mapping, Abruf, Parsing und Ergebnis brauchten eigene Belege.

Die Aufgabe war Namenstransport, nicht Ortung

Eine externe XML-Entity hatte System- und Public-Identifier. Der erste war per Definition URI und oft lokal. Der zweite war eine SGML-erbende Zeichenfolge, die als globalerer, dauerhafter Name diente.

URI-Pflicht in neueren Spezifikationen machte den alten Namen unpassend. RFC 3151 ersetzte installierte Kataloge nicht, sondern schuf den formalen Namespace publicid, um die Zeichenfolge als URN auszudrücken.

Die URI-Form sah nach Autorität aus, verlieh sie aber nicht. Eindeutigkeit und Persistenz kamen weiterhin vom Quellbezeichner. Ein unregistrierter Eigentümer und schwache Vergabe blieben schwach.

Das Informational RFC erklärte ausdrücklich, keinen Internetstandard festzulegen. Beispiele waren pädagogisch und nicht garantiert real. Sie belegten eine Regel, keine Registrierung oder Erreichbarkeit.

Normalisierung tauschte Historie gegen Vergleichbarkeit

Vor der Transkription wurden Folgen aus Leerzeichen, Tab, Wagenrücklauf und Zeilenumbruch zu einem Leerzeichen; Ränder verschwanden. Unterschiedlich eingerückte Quellen konnten denselben Namen ergeben.

Diese Informationsvernichtung war beabsichtigt. Wer nur die URN speicherte, verlor das ursprüngliche Layout. Quellstring, Codierung, Normalisierung und Regelversion gehörten deshalb zusammen.

Ein normalisiertes Leerzeichen wurde +; ein literales Plus wurde %2B. Durch vorheriges Zusammenfassen durften aus Leerraum keine benachbarten Pluszeichen entstehen. Die beiden Formen belegten verschiedene Ausgangszeichen.

Ein plausibles Endergebnis bewies nicht, dass Normalisierung vor dem Escaping geschah. Zwischenschritte mussten sichtbar bleiben.

Sichtbare Struktur war keine Beglaubigung

Formal Public Identifiers enthielten typischerweise Eigentümer, Klasse, Beschreibung, Sprache und optional Version. // trennte Felder, :: konnte intern auftreten.

RFC 3151 machte aus // einen Doppelpunkt und aus :: ein Semikolon. So blieb die Form erkennbar, ohne die vollständige SGML-Grammatik zu implementieren. FPI-Validierung lag außerhalb des Verfahrens.

Ein Doppelpunkt bewies also ein Doppel-Slash im normalisierten Input, nicht Eigentümerregistrierung oder gültige Felder.

Literale Zeichen mussten anders laufen: einzelner Doppelpunkt wurde %3A, einzelner Slash %2F, Semikolon %3B; Apostroph, Fragezeichen, Raute und Prozent wurden ebenfalls escaped. Position und Ersetzungsreihenfolge waren Teil des Belegs.

Round-Trip-Tests konnten Namensbewahrung, aber keine Zuweisung oder Auflösung bestätigen.

Zeichenidentität endete an der Namensgrenze

Äquivalenz galt genau dann, wenn normalisierte URNs lexikalisch identisch waren. Es gab kein Case Folding, keine Eigentümer-Aliase und keine semantische Feldgleichheit.

Ein lokaler Katalog konnte zwei Namen auf eine Datei abbilden, ohne die Namen gleich zu machen. Derselbe Name konnte auf zwei Maschinen durch verschiedene Katalogketten und Caches zu anderen Dateien führen.

Eine Ressource durfte mehrere öffentliche Bezeichner haben. Namens-, Mapping-, Byte- und Verhaltensgleichheit waren daher vier getrennte Prüfungen. Spätere URI/URN-RFCs erweiterten die historische 3151-Regel nicht rückwirkend.

Die Schwächen des Eigentümers wanderten mit

FPIs mit registriertem Eigentümer sollten eindeutig sein. Informelle Namen und unregistrierte Eigentümer konnten kollidieren; eine einheitliche Durchsetzung wurde nicht behauptet.

Persistenz wurde ebenfalls geerbt. Registrierung half, garantierte aber weder Katalog noch Inhalt. Das domainbasierte IDN-Eigentümerschema erbte mindestens die Persistenzschwächen von Domainnamen.

urn:publicid: reparierte keine Vergabe, hielt keinen Dienst am Leben und fror keine Repräsentation ein. Eine Ressource ohne Public-Identifier brauchte zuerst einen nach dessen Regeln; erst dann folgte die Transkription.

Eigentümer, Registrierungsstand, Politik, Zeitpunkt und Kontext mussten neben der Zeichenfolge stehen.

Auflösung blieb eine lokale Entscheidungskette

Das RFC nannte OASIS-Kataloge, lokale Pfadabbildung, fest eingebautes Wissen und Caches. Es definierte keinen einzigen globalen Resolver.

Katalogreihenfolge, Rewrite-Regel, Basis-URI, Mount, Netz und Cache-Alter bestimmten das Ziel. Ein Match belegte Auswahl, nicht Abruf.

Danach folgten Bytes und Hash, Parser und Entity-Policy, Diagnose und Anwendungsergebnis. resolved=true war für diese Kette zu grob.

Kein Validierungsmechanismus war angegeben. Keine zusätzlichen Security Considerations bedeuteten nicht, dass Eigentümer, Katalog, Cache oder Inhalt authentisiert waren. Ein korrekter Encoder konnte präzise zur veralteten Datei führen.

Laufender Code durfte den perfekten Namen korrigieren

Eine perfekte URN kann eine alte lokale DTD finden. Regel, Dateiöffnung und Parsing gelingen, während die Anwendung die falsche Version nutzt. Eine zweite Maschine kann mit derselben URN andere Bytes wählen.

Die RFC-Tabelle ist für Transkription maßgeblich. Laufendes Verhalten zeigt Resolver, Siegerregel, Bytes und Wirkung. Kein Beleg darf den nächsten ersetzen.

Die historische Leistung war sauber begrenzt: Der alte Name gelangte in die URI-Architektur, ohne sich als Ort auszugeben. Damit war Auflösung noch nicht vollendet.

Quellen