要約

  • RFC 9535 のJSONPathは、一つの具体的なJSON値を対象に評価され、ゼロ個以上のノードからなるノードリストを返す。各ノードには、その値の中で一意の正規化パスがある。
  • $['approvals'][3] は現時点の4番目の承認を正確に指せる。しかし先頭に要素が追加されれば、同じ文字列が別の承認を指す。位置の一意性は履歴をまたぐ同一性ではない。
  • 空の結果、JSONのnull、重複選択、範囲外の添字は別々の状態である。重要な判断には入力、クエリ、実装、結果、方針を結び付けた記録が要る。

座席番号は人を識別しない。搭乗者が入れ替われば、同じ「4A」は別の人を示す。JSON配列の位置も同じである。

午前9時に $['approvals'][3] がある承認を選んだとする。午前9時5分に古い申請が先頭へ挿入された。クエリは変わらず、構文も正しく、結果も一件だが、対象は移動している。このときパスだけを保存していたシステムは、再現可能な座標を永続的な識別子と取り違える。

RFC 9535 はこの境界を明示する。2024年2月にIETF標準トラックで発行された同文書は、一つのJSON値をクエリ引数として評価し、ノードリストを得る共通規則を定めた。ノードとは、値と、その入力内での位置を組み合わせたものだ。標準化されたのは選択の仕組みであって、入力の権威や業務上の意味ではない。

正規化パスは現在地を固定する

正規化パスは、標準的な角括弧表記とエスケープを用い、特定の値にある一つのノードを指す。その値の各ノードについて正規化パスは一つだけなので、テスト、結果比較、後処理、明示的な重複除去に向く。「実装がどこを選んだか」を曖昧さなく保存できる。

ただし、パスには入力のハッシュ、文書版、出所、スキーマ版、業務IDが含まれない。負の配列添字で一件に絞れるクエリも、正規化時には具体的な配列長から解決した非負添字になる。入力が変われば、同じ論理対象を指す保証は消える。

JSON Pointerを定めるRFC 6901 も既知の構造内の場所を表し、正規化JSONPathから変換できる。表記を変えても、場所が永続IDに昇格するわけではない。

空、null、失敗を一つにしない

空のノードリストはRFC 9535上の正常な結果である。配列添字が範囲外なら、そのセグメントは単にノードを選ばず、後続も空になる。これはクエリの構文エラー、タイムアウト、資源上限、パーサ拒否とは異なる。

JSONのnullとも異なる。nullは存在する値であり、メンバーがない場合はノードそのものがない。認可処理が両者を同じ偽値へ落とせば、JSONPathの評価は正しくても方針は誤る。

同一ノードを複数回選べば、重複はノードリストに残る。count()は一意な値や業務対象ではなくノードを数える。複数の順序が許される場面では、実装が評価ごとに別の許容順序を返すこともある。「先頭を採用」は、外部契約が順序を定義しない限り、アプリケーション独自の判断である。

合意できる選択と、信用できる事実は別物だ

RFC 8259 はJSONを定義し、オブジェクトの重複メンバー名が相互運用性を損なうと警告する。RFC 7493 のI-JSONは予測可能性を高め、RFC 9485 はmatch()とsearch()に共通の正規表現プロファイルを与える。IANAのJSONPathレジストリ は拡張関数を管理し、application/jsonpath はクエリ文書の媒体型を登録する。

これらは実装間の合意を強める。しかし、ownerという名前が法的所有者を意味すること、リスク値が最新であること、文書が正当な発行者から来たことまでは保証しない。

RFC 9537 は、RDAP応答で秘匿されたフィールドの位置をJSONPathで示す。位置はその応答の秘匿箇所を正確に示せるが、隠された値、秘匿方針の正当性、過去応答の内容を証明しない。座標と権威の違いがよく見える例である。

ドル記号より前に安全性を確認する

RFC 9535 は、任意のクエリ断片をホスト言語のevalへ渡す実装を禁じる方向で注意を促す。メンバー名や添字、比較値を文字列へ差し込む場合も検証とエスケープが必要だ。素朴な再帰下降は、細工された入力によってCPU消費やスタック枯渇を招く可能性がある。正しい文法だけでは、無制限の評価を安全にはしない。

UTF-8のRFC 3629 と RFC 8949 が扱うデータモデル上の配慮は表現を安定させるが、出所や認可までは生まない。必要なのは、元バイト列、解析済み値、クエリ、実装と拡張、ノードリスト、アプリケーション解釈、最終判断をつなぐ証拠である。

判断を再生できる受領書

アクセス制御、コンプライアンス、ルーティング方針、事故対応にJSONPathを用いるなら、入力または暗号学的ハッシュと出所、パーサ版と重複名処理、クエリ原文と媒体型、変数の検証前後、実装版、拡張関数、時間・メモリ・深さ制限、正規化パスと許可された値、評価後の重複除去、順序の根拠、スキーマ・方針版、判断者・時刻・結果を残す。

これで言えるのは「実装Xが制限Lの下、ハッシュHの入力にクエリQを実行し、これらの場所を返した」までだ。昨日と同じ記録だと言うには、安定IDと版をまたぐ対応証拠が別に要る。

参照資料と限界

RFC 9535 は HTML、テキスト、情報ページ、Datatracker、履歴、正誤表検索 で確認できる。策定過程は IETF作業リポジトリ、実装差の背景は JSONPath比較プロジェクト にある。

関連資料はRFC 8259、7493、9485、6901、8949、3629、9537、IANAレジストリ、媒体型登録 である。統治面の視点には、Heng Luの現実層と象徴権力、最小初期仕様、動くコードの優先 を用いた。

特定の実装、サービス、障害、攻撃は調査していない。RFC 9535の欠陥や、特定組織による誤用を主張するものではない。