Zusammenfassung

  • RFC 3076 kanonisierte keine unangetastete Datei. Ein XML-Prozessor wandelte den Oktettstrom zunächst in einen XPath-Knotensatz um und normalisierte oder erweiterte dabei bereits Informationen.
  • Gleiche kanonische Bytes waren ein genauer Beleg für dieses Modell, die Kommentaroption und den Algorithmus; sie rekonstruierten weder die Quelle noch bewahrten sie automatisch DTD-, Basis-URI- oder Anwendungssemantik.

Die stabile Darstellung begann in der Mitte

Im März 2001 lösten RFC 3076 und die W3C Recommendation Canonical XML Version 1.0 ein praktisches Problem. XML erlaubte verschiedene physische Schreibweisen für Informationen, die viele Anwendungen als gleich behandelten. Attributreihenfolge, Zeichenkodierung, Kurzform leerer Elemente und Referenzen konnten variieren. Signaturen und Integritätsvergleiche brauchten eine gemeinsame Darstellung.

Das Verfahren erzeugte UTF-8, entfernte XML-Deklaration und DTD, schrieb leere Elemente als Start- und End-Tag, legte Anführungszeichen fest, entfernte überflüssige Namespace-Deklarationen und sortierte Namespaces und Attribute. Kommentare waren eine ausdrückliche Option. Eine wohlgeformte kanonische Ausgabe änderte sich bei erneuter Anwendung desselben Verfahrens nicht.

Doch das formale Objekt war ein XPath-Knotensatz. Ein eingehender Oktettstrom musste zuerst geparst werden. Der Kanonisierer erhielt kein rohes Dokument, sondern ein bereits konstruiertes Datenmodell.

Der Parser hatte das Objekt schon hergestellt

Der XML-Prozessor normalisierte Zeilenenden und Attributwerte, ersetzte CDATA durch Zeicheninhalt, löste Zeichen- und geparste Entitätsreferenzen auf und konnte Standardattribute aus einer DTD hinzufügen. Namespaces wurden Knoten, aufeinanderfolgende Zeichen Textknoten.

So konnten unterschiedliche Quellen absichtlich konvergieren. Ein literales Zeichen und seine numerische Referenz, eine interne Entität und ihr Ersetzungstext oder <e/> und <e></e> konnten dasselbe Modell ergeben. Diese Konvergenz war der Nutzen der Norm.

Sie machte die Ausgabe zugleich ungeeignet, die ursprüngliche Schreibweise zurückzugewinnen. Die Ausgangskodierung wich UTF-8, XML-Deklaration und DTD verschwanden, Grenzen von Entitäten und CDATA wurden aufgelöst und die ursprüngliche Attributreihenfolge ersetzt. Die kanonische Form beantwortete, wie das Modell deterministisch serialisiert wird, nicht welche Bytes und externen Ressourcen es erzeugten.

Die Belegkette muss deshalb früher beginnen: Hash der empfangenen Bytes, Abruf-URI und Zeitpunkt, deklarierte Kodierung, Parser und Einstellungen, Validierung, Zugriffspolitik für externe Teilmengen und Entitäten, tatsächliche Bytes jeder Abhängigkeit, Basis-URI und ergänzte Standardattribute. Aus dem Endhash lässt sich das nicht zurückrechnen.

Gleiche Ausgabe konnte Verhalten verlieren

RFC 3076 nannte Informationen, die im XPath-Modell fehlen: Basis-URI, besonders für Ersetzungstext externer geparster Entitäten; Notationen und externe ungeparste Entitäten; sowie in der DTD deklarierte Attributtypen.

Eine externe Entität kann eine relative URI enthalten. Nach dem Einfügen ihres Textes in das Hauptdokument kann diese Zeichenfolge gegen einen anderen Ort aufgelöst werden, wenn die ursprüngliche Basis verloren geht. Die kanonischen Bytes bleiben stabil, während die Anwendung eine andere Ressource erreicht. Der RFC empfahl geeignetes xml:base oder vorherige Umwandlung in absolute URIs.

Bei der DTD entsteht eine weitere Asymmetrie. Ein Standardattribut kann bereits im Knoten und in der Ausgabe stehen, während seine Quelle entfernt wurde. Typen wie ID, IDREF, Aufzählung und NOTATION begleiten die kanonische Datei nicht mehr. Ein späterer Parser liest den Wert, aber nicht zwingend den ursprünglichen Typvertrag.

Notationen und ungeparste Entitäten konnten externe Daten an Anwendungen binden. Das Modell bewahrte nicht jede solche Bindung. „Ungewöhnlich“ war eine Häufigkeitsangabe, kein Grund, bei tatsächlicher Nutzung auf Herkunftsbelege zu verzichten.

Ein Knotensatz war nicht automatisch ein vollständiger Teilbaum

Bei Dokumentteilen lieferte XPath einzelne Knoten. Ein ausgewähltes Element schloss Attribute, Text und Nachkommen nicht automatisch ein. Ein ausgeschlossener Knoten wurde nicht ausgegeben, nur weil sein Elternknoten enthalten war. Zugleich konnten ausgelassene Vorfahren Namespace-Kontext oder vererbbare XML-Attribute beitragen.

Der Ersteller des Knotensatzes musste daher die nötige Semantik erhalten. Eine kanonische Teilausgabe konnte sogar nicht wohlgeformtes XML sein. „Kanonisch“ bewies weder Vollständigkeit noch Selbstständigkeit.

Diese Grenze liegt vor der Frage aus RFC 3075. Dort geht es um signierte References und Transformationen. Hier geht es um das Objekt, das der Parser zuvor geschaffen hat. Eine korrekte Signatur ersetzt keine fehlende Parserprovenienz.

Kanonisch bedeutete nicht jede denkbare Äquivalenz

Der RFC machte die kanonische Form nicht zum Genau-dann-wenn-Test für jede Bedeutung. Eine Anwendung konnte Leerraum ignorieren oder black und rgb(0,0,0) als dieselbe Farbe behandeln. Andere Spezifikationen konnten weitere Gleichheiten definieren. Verschiedene Formen konnten für einen Zweck gleich sein.

Auch eine allgemeine Unicode-Zeichenmodellnormalisierung fand nicht statt. Namespace-Präfixe blieben erhalten, weil eine Umschreibung eingebettete XPath- oder QName-artige Werte beschädigen konnte. Der Vertrag war begrenzt und ausführbar, kein universeller Semantikprüfer.

Spätere Arbeit zeigte den Kontext erneut

Eine W3C Note von 2006 dokumentierte, dass C14N 1.0 ein relatives xml:base auf einen ausgewählten Nachfahren kopieren konnte, ohne den Pfad der ausgelassenen Vorfahren zusammenzusetzen. Das später standardisierte xml:id durfte ebenfalls nicht wie ein gewöhnliches XML-Attribut vererbt werden.

Canonical XML 1.1 änderte 2008 beide Regeln: kein geerbtes xml:id, besondere Pfadbehandlung für xml:base. Das belegt Evolution, nicht das Versagen jeder früheren Installation. Exclusive XML Canonicalization behandelte Namespace-Kontext bei verschobenen Fragmenten. RFC 3275 verwendete C14N 1.0 in XML Signature. Keine dieser Schichten bewies Originalbytes oder Autorisierung.

Was erhalten bleiben muss

Zu speichern sind Quelloktette, Herkunft, Kodierung und Hash; Parser und Einstellungen; Validierung; verwendete DTDs, Kataloge und Entitäten; Basis-URI; Standardattribute; XPath-Auswahl und Ergebnis; Kommentaroption; Methode und Version; kanonische Ausgabe. Danach folgen Vergleichs- oder Signaturergebnis, anwendungseigene Äquivalenzregel, Entscheidung und beobachtete Wirkung.

Lu Hengs spätere Argumente über laufenden Code und Realitätsebenen dienen als offengelegte Linse. Reproduzierbare Bytes sind stärker als ein Etikett. Der Ausführungsbeleg übernimmt dennoch nicht Quellgeschichte, Autorität oder Ergebnis.

Quellen