Zusammenfassung

  • Ein Erfolg nach RFC 5261 beweist, dass ein Selektor in dem gelieferten XML-Baum genau einen Knoten fand und die definierte Mutation erzeugt wurde; er beweist nicht, dass dieser Baum die beabsichtigte aktuelle Basis war.
  • Ein belastbarer Patch-Beleg muss Basisbytes und Version, Selektorkontext, jeden Zwischenzustand, Fehlerstelle, Transaktionsregel, fachliche Prüfung sowie die abschließende Speicher- und Veröffentlichungsbeobachtung verbinden.

Die Kennung war eindeutig – nur nicht für diesen Parser

Ein Konfigurationssystem erzeugt einen Patch mit id(). In der Entwicklungsumgebung findet der Selektor genau das erwartete Element. In der Produktion behandelt der Parser dasselbe Attribut nicht als ID, weil dort weder die passende Schemainformation noch dieselbe xml:id-Verarbeitung verfügbar ist. Der Patch scheitert oder weicht auf eine andere Auswahlstrategie aus.

RFC 5261 erlaubt id() unter klaren Voraussetzungen. Seine Nützlichkeit hängt aber von Schema, Dokumentmodell und Prozessorunterstützung ab. Die Zeichenfolge einer Kennung allein schafft noch keine dauerhafte Objektidentität.

Damit wird eine verbreitete Verwechslung sichtbar: Ein formal eindeutiger Bezeichner ist nicht automatisch eine über Systeme und Versionen hinweg geteilte Identitätszusage.

Ein Selektor beantwortet nur die Frage im vorgelegten Baum

Jede Operation besitzt sel, einen Ausdruck aus einer eingeschränkten Teilmenge von XPath 1.0. Er muss genau einen Zielknoten lokalisieren. Null Treffer und mehrere Treffer sind Fehler. Namen, Platzhalter, Prädikate, Werte, Positionen und gegebenenfalls id() verengen die Auswahl.

Diese Eindeutigkeit sagt nichts darüber aus, ob das Dokument die aktuelle genehmigte Revision ist. Ein eingeschobenes Geschwisterelement verschiebt Positionsangaben. Attributwerte können wiederverwendet werden. Auch eine echte XML-ID bindet den Patch nicht von selbst an einen Geschäftsfall oder eine Freigabe.

Deshalb braucht der Beleg neben dem Ausdruck den Hash der Basis, Version oder ETag, aufgelöste Namensräume, den tatsächlich gefundenen Pfad und den Vorher-Hash des Knotens. Nur so wird aus einer wiederholbaren Syntax ein historisch bestimmbarer Vorgang.

Die Operationsfolge ist Teil des Programms

add, replace und remove werden der Reihe nach ausgeführt. Nach jedem Erfolg wird das gepatchte Dokument zum eigenständigen Ziel der nächsten Operation. Eine Einfügung kann Positionsangaben verschieben; eine Entfernung kann Textknoten zusammenführen; qualifizierter Inhalt kann eine Umschreibung von Präfixen auslösen.

Dieselben Operationen in anderer Reihenfolge können andere Knoten treffen und ein anderes Enddokument erzeugen. Reihenfolge ist keine beiläufige Protokollinformation, sondern Semantik.

Bei folgenreichen Änderungen gehören Operationsnummer, Knotenvorbild und Hash jedes Zwischendokuments in eine fortlaufende Beweiskette. Ein Endhash allein zeigt nicht, ob die Implementierung Schritte umgeordnet, ausgelassen oder trotz Fehler fortgesetzt hat.

Ein Fehler definiert keinen universellen Rollback

Kann eine Operation nicht eindeutig erfüllt werden, liegt laut RFC 5261 ein Fehler vor; weitere Verarbeitung sei kaum sinnvoll. Der Standard beschreibt Fehler für nicht gefundene Knoten, unzulässige Knotentypen, Namensraumprobleme, nicht unterstützte IDs und weitere Fälle.

Er schreibt jedoch nicht für jede einbettende Anwendung dieselbe Speichertransaktion vor. Vor einem späten Fehler können Zwischenstände im Speicher entstanden, dauerhaft geschrieben oder anderen Komponenten sichtbar geworden sein. Commit und Rücknahme sind Pflichten des umgebenden Protokolls und der Implementierung.

Die Meldung „Patch fehlgeschlagen“ ist daher kein Zustandsnachweis. Sie braucht die fehlgeschlagene Operationsnummer, den letzten erfolgreichen Zwischenhash und eine beobachtete Aussage darüber, was geschrieben oder zurückgenommen wurde.

Namensraum-URI und Präfixschreibweise sind nicht dasselbe

Präfixe gelten lokal. Diff und Zieldokument dürfen verschiedene Präfixe für dieselbe Namensraum-URI verwenden; beim Hinzufügen kann der Prozessor Präfixe umschreiben. Für Standardnamensräume legt RFC 5261 in bestimmten Selektoren ein bewusst definiertes Verhalten fest, das nicht durch gewöhnliche XPath-Annahmen ersetzt werden darf.

Eine Präfixänderung kann im XML-Modell bedeutungsgleich sein. Nachgelagerter Code, der Schreibweise fälschlich als Identität behandelt, kann dennoch anders reagieren. Standardkonformität des Patch-Prozessors und Korrektheit des Verbrauchers bleiben getrennte Prüfungen.

Kanonische Gleichheit ist keine fachliche Gleichheit

Das Rahmenwerk verwendet Canonical XML mit Kommentaren, um logische Gleichwertigkeit für die deterministische Verarbeitung zu bestimmen. Es behandelt Text und Leerraum sorgfältig, weil benachbarte Textknoten im Datenmodell zusammenfallen.

Damit ist nicht bestätigt, dass Berechtigungen, Preise, Signaturumfang oder Workflowregeln gewahrt bleiben. Ein Dokument kann wohlgeformt, schemakonform und kanonisch stabil sein und dennoch eine unzulässige Entscheidung ausdrücken. Technische Wahrheit in der Darstellungsebene ist keine Genehmigung in der Entscheidungsebene.

Versionsgeschichte bleibt Sache der Anwendung

RFC 5261 erkennt an, dass manche Anwendungen eine vollständige Versionsgeschichte einschließlich scheinbar überflüssiger Änderungen benötigen, verlangt aber keine allgemeine Lösung. Er weist zudem auf die Fragilität kurzer Positionsselektoren nach Einfügungen und Löschungen hin.

Diese Grenze ist bewusst. Wer Aktualität sichern muss, ergänzt Quellhash, Generation, Version oder ETag als Vorbedingung. Wer Atomarität braucht, definiert einen Commit. Wer Legitimität braucht, bindet Akteur und Berechtigungsumfang an exakt diese Basis.

Der Nachweis einer verantwortbaren Änderung

Für wichtige Aktualisierungen sind mindestens zu bewahren:

  • Zielobjekt, exakte Basisbytes, Hash, Version, ETag oder Generation;
  • Diff-Bytes und -Hash, Medientyp, Zeichensatz, Schema und authentifizierter Akteur;
  • geordnete Operationsnummer, Selektortext und aufgelöste Namensraumbindungen;
  • Pfad, Typ und Vorher-Hash des gefundenen Knotens;
  • Operationsinhalt und Hash jedes Zwischendokuments;
  • Fehler, fehlgeschlagene Operation und letzter erfolgreicher Zustand;
  • Rollback- oder Commit-Regel und das beobachtete Ergebnis;
  • Endhash, Schema- und fachliche Validierung; sowie
  • Speicherbestätigung, Replikation und sichtbare Veröffentlichung.

Dieser Nachweis autorisiert den Patch nicht. Er verhindert, dass „der Selektor traf“ zu „die Organisation genehmigte die richtige Änderung an der richtigen Version“ umgedeutet wird.

Sources