Zusammenfassung

  • RFC 9535 definiert die Auswertung einer JSONPath-Abfrage gegen einen konkreten JSON-Wert. Das Ergebnis ist eine Liste aus null oder mehr Knoten; jeder Knoten hat in diesem Wert genau einen Normalisierten Pfad.
  • $['approvals'][3] kann heute eindeutig die vierte Freigabe bezeichnen. Wird davor ein Element eingefügt, kann dieselbe Zeichenfolge morgen eine andere Freigabe treffen.
  • Leere Liste, JSON-null, doppelte Auswahl und Index außerhalb des Bereichs sind verschiedene Zustände. Eine belastbare Entscheidung bindet Eingabe, Abfrage, Implementierung, Ergebnis und Richtlinie zusammen.

Ein präziser Sitzplatz ist noch keine dauerhafte Personenkennung.

Um 9 Uhr wählt $['approvals'][3] die Freigabe von A. Fünf Minuten später wird am Anfang des Arrays ein älterer Antrag eingefügt. Die Abfrage bleibt gültig und liefert weiterhin einen Knoten, doch an Position vier sitzt nun B. Hat das System nur den Pfad gespeichert, kann es seine frühere Beobachtung nicht mehr belegen.

Das widerspricht RFC 9535 nicht. Der im Februar 2024 auf dem IETF Standards Track veröffentlichte RFC beschreibt eine Abfrage gegen einen JSON-Wert, das Query Argument, und eine daraus entstehende Knotenliste. Ein Knoten verbindet einen Wert mit seinem Ort in genau dieser Eingabe. Standardisiert wird die Auswahl, nicht die Autorität des Dokuments oder die fachliche Identität.

Kanonisch heißt ortsfest, nicht zeitfest

Ein Normalisierter Pfad verwendet kanonische Klammernotation und Maskierung. Für jeden Knoten eines bestimmten Werts existiert genau einer. Das ist nützlich für Tests, Ergebnisvergleiche, Nachverarbeitung und explizite Deduplizierung.

Im Pfad fehlen jedoch Dokument-Hash, Version, Herkunft, Schema und stabile Objekt-ID. Selbst ein negativer Arrayindex hängt von der konkreten Länge ab; der normalisierte Pfad enthält die daraus berechnete nichtnegative Position. Ändert sich die Länge, kann die fachliche Zuordnung brechen.

JSON Pointer nach RFC 6901 lokalisiert ebenfalls einen Wert in bekannter Struktur; ein Normalisierter Pfad lässt sich in einen Pointer überführen. Die Umwandlung erzeugt keine historische Kontinuität.

Ein leeres Ergebnis erklärt seine Ursache nicht

Eine leere Knotenliste ist gültig. Ein Index außerhalb des Bereichs wählt lediglich weniger Knoten; weitere Segmente bleiben leer. Das ist weder Syntaxfehler noch Timeout, Ressourcenlimit oder Parser-Ablehnung.

Ebenso wenig ist es JSON-null: null ist ein vorhandener Wert, ein fehlendes Mitglied liefert keinen Knoten. Werden beide Fälle zu einem pauschalen Falschwert verdichtet, kann die Engine korrekt und die Zugriffsregel falsch sein.

Mehrfach ausgewählte Knoten bleiben mehrfach enthalten. count() zählt Knoten, nicht eindeutige Werte oder Geschäftsobjekte. Wo mehrere Reihenfolgen zulässig sind, können aufeinanderfolgende Auswertungen verschieden und dennoch konform sortiert sein. „Nimm den ersten“ ist eine Anwendungsregel, sofern kein anderer Vertrag die Ordnung festlegt.

Mechanische Einigkeit ist kein Wahrheitsbeleg

RFC 8259 definiert JSON und warnt vor doppelten Mitgliedsnamen; RFC 7493 engt mit I-JSON problematische Varianten ein. RFC 9485 liefert das Regex-Profil für match() und search(). Das IANA-Register führt Erweiterungen, application/jsonpath kennzeichnet Abfragedokumente.

Diese Vereinbarungen erhöhen die Chance gleicher Auswahl. Sie beweisen nicht, dass owner den rechtlichen Eigentümer nennt, Daten aktuell sind oder die Quelle befugt war. RFC 9537 zeigt die Grenze: JSONPath lokalisiert eine geschwärzte Stelle in einer RDAP-Antwort, legt aber weder den verborgenen Wert noch die Berechtigung der Schwärzung offen.

Sicherheit beginnt vor der Auswertung

RFC 9535 warnt davor, Fragmente an das eval der Wirtssprache zu übergeben. Eingesetzte Namen, Indizes und Vergleichswerte müssen geprüft und maskiert werden. Naive rekursive Abfragen können außerdem extreme CPU-Last oder Stacküberlauf auslösen. Korrekte Grammatik braucht begrenzte Ressourcen und eindeutige Fehlerzustände.

UTF-8 nach RFC 3629 und Modellüberlegungen aus RFC 8949 stabilisieren die Darstellung, nicht die Herkunft. Die vollständige Kette lautet: Quellbytes, geparster Wert, Abfrage, Implementierung und Erweiterungen, Knotenliste, Interpretation, Entscheidung.

Ein Beleg, der die Entscheidung reproduzierbar macht

Für Zugriff, Compliance, Routing oder Vorfallbearbeitung gehören in den Beleg: Eingabe oder Hash samt Herkunft; Parser und Umgang mit doppelten Namen; exakte Abfrage und Medientyp; Variablen vor und nach Prüfung; Implementierung, Version und Erweiterungen; Zeit- und Ressourcenlimits; Normalisierte Pfade und zulässige Werte; spätere Deduplizierung und Sortierung; Schema, Richtlinie, Akteur, Zeitpunkt und Ergebnis.

Damit lässt sich sagen: X führte Q gegen Eingabe-Hash H unter Grenzen L aus und erhielt diese Orte. Für „derselbe Datensatz wie gestern“ braucht es zusätzlich eine stabile Schema-ID und eine versionsübergreifende Zuordnung.

Quellen und Grenzen

Der amtliche Bestand umfasst HTML, Text, die Infoseite, den Datatracker, dessen Historie und die Errata-Suche. Das Arbeitsgruppen-Repository dokumentiert die Entstehung, der JSONPath-Vergleich die frühere Fragmentierung.

Weitere Quellen sind RFC 8259, 7493, 9485, 6901, 8949, 3629 und 9537, das IANA-Register und der Medientyp. Die Governance-Perspektive folgt Heng Lu zu Realitätsebenen, minimaler Anfangsspezifikation und Vorrang laufenden Codes.

Keine benannte Implementierung, Organisation, Attacke oder Störung wurde untersucht. Der Beitrag behauptet weder einen Fehler in RFC 9535 noch einen konkreten Missbrauch.