要約

  • RFC 5261 の成功が証明するのは、供給された XML 木でセレクターが一つのノードに一致し、指定された変更を生んだことまでであり、その木が正しい現行基準版だったことではない。
  • 重大な変更の証跡には、基準版のバイト列と版、セレクターの文脈、各中間状態、失敗地点、ロールバックまたは確定の結果、最終的な業務検証と公開観測が必要になる。

空白を消しただけなのに、次の対象が変わった

ある設定文書では、見栄えを整えるための空白テキストノードが要素の間に置かれていた。最初の操作が要素を削除すると、その両側のテキストは一つにまとめられた。続く操作は位置と文字列値を手掛かりにしていたため、作成者が想像した木とは別の状態を相手にした。

XML のデータモデルは隣接するテキストノードを別々のまま保持しない。RFC 5261 は、追加・置換・削除に伴う結合や空白処理を明示し、結果を決定的にする。それでも、利用側が改行やノード境界に隠れた意味を持たせていれば、仕様どおりのパッチがアプリケーションの振る舞いを変える。

「文字列として同じに見える」と「同じ業務状態である」は別の判定だ。ここに XML 処理の成功と制度的な正しさの境界がある。

一意の選択は現在の木にだけ効く

各操作の sel は、制限された XPath 1.0 の式で対象を一つだけ指さなければならない。ゼロ件も複数件もエラーになる。名前、述語、値、位置、そして条件が整った場合の id() が利用できる。

しかし、一意性はその入力文書内での性質にすぎない。兄弟要素の追加で位置はずれ、属性値は再利用され得る。id() もスキーマや xml:id、処理系の対応がなければ、永続的な識別子として働かない。

証跡には式だけでなく、基準版のハッシュ、展開後の名前空間、実際に一致したパス、ノードの変更前ハッシュを残す必要がある。それがなければ再現できるのは構文だけで、当時の対象ではない。

各操作は次の世界を作る

add、replace、remove は順に処理される。成功した文書が、次の操作にとって独立した新しい対象になる。先頭への挿入は後続の位置セレクターをずらし、削除はテキストを結合し、名前空間の追加は表記を変え得る。

順序は単なるログ属性ではなく、パッチそのものの意味である。同じ操作集合でも並べ方が違えば、別のノードに触れ、別の文書を作る。最終ファイルだけを保存しても、どの経路を通ったかは分からない。

だから高リスクの処理では、操作番号、セレクター、変更前ノード、各中間文書のハッシュを連続した鎖として保存すべきだ。実行順を失った監査記録は、結果を説明できても因果を立証できない。

エラーは万能のロールバック命令ではない

一つの操作を明確に実行できなければエラーとなり、その後を続けるのはほとんど意味がない、と RFC 5261 は述べる。位置不明、無効なノード種別、名前空間や ID の問題など、詳細なエラー要素も定義されている。

一方で、どの利用形態にも共通するストレージ・トランザクションは規定されない。後半の失敗までに作られた状態がメモリーだけにあったのか、外部へ書かれたのか、完全に取り消されたのかは周辺プロトコルと実装の責任だ。

したがって「パッチ失敗」は状態報告として不十分である。失敗した操作、最後に成功した中間ハッシュ、永続化の有無、ロールバックの観測結果がそろって初めて意味を持つ。

接頭辞の綴りと名前空間の同一性を分ける

接頭辞の有効範囲は局所的である。差分文書と対象文書が別の接頭辞で同じ名前空間 URI を表してもよい。追加内容を配置するときに接頭辞が書き換えられることもある。既定名前空間については、RFC 5261 が通常の XPath の思い込みとは異なる規則を明示している箇所もある。

URI が同じなら、接頭辞の変化は XML モデル上の意味を保ち得る。しかし下流のコードが綴りを同一性として扱うなら、正当な書き換えでも障害になる。セレクターを記録する際は、当時の URI への展開を併記しなければならない。

正規化された同値性は業務判断ではない

この枠組みはコメント付き Canonical XML を使い、決定的な処理のための論理的同値性を定める。これは重要だが、権限、料金、署名範囲、承認経路などの不変条件を認証するものではない。

文書が整形式で、スキーマに適合し、正規化後にも安定していても、業務規則には違反し得る。技術層の真実を、そのまま意思決定層の承認に昇格させてはならない。

版の履歴は利用側が設計する

RFC 5261 は、余分に見える変更まで含む完全な版履歴を必要とするアプリケーションがあると認めつつ、共通の方式を命じていない。短い位置セレクターが挿入や削除によって壊れやすいことも説明する。

この沈黙は責任の所在を示す。現行版保証が必要なら ETag、世代番号、元文書ハッシュなどの前提条件を加える。原子性が必要ならコミット境界を定める。権限が問題なら主体と対象範囲を基準版に結び付ける。

パッチの意思決定証跡

重要な更新では、少なくとも次を保存する。

  • 対象オブジェクト、基準版の正確なバイト列、ハッシュ、版、ETag または世代番号
  • 差分のバイト列とハッシュ、媒体型、文字コード、スキーマ、認証された主体
  • 操作番号、セレクター本文、展開済み名前空間
  • 一致したノードのパス、型、変更前ハッシュ
  • 操作内容と各中間文書のハッシュ
  • エラー要素、失敗番号、最後の成功状態
  • ロールバックまたはコミット方針と実際の結果
  • 最終ハッシュ、スキーマ検証と業務意味の検証
  • 保存確認、複製、読者から見える公開状態

この証跡自体が変更を承認するわけではない。セレクターの成功を、正しい現行対象への正当な変更という主張にすり替えさせないためにある。

Sources