Na JSON se rozhodně dá nahlížet jako na strom. Pole a objekty jsou uzly, z nichž vedou vazby na uzly, které reprezentují vnořené hodnoty. Všechny ostatní typy (čísla, řetězce, booleany a nully) jsou pak koncové uzly.
Spousta knihoven pro manipulaci s JSON dokumenty tuto reprezentaci poskytuje, viz třeba JsonNode v System.Text.Json.
Ale holt stejně jako ne každý řetězec je platný JSON text, tak ne každý strom je platný JSON dokument.
To že použivate knižnicu ktorá vám parsuje JSON do AST a AST vie previesť na text(JSON), rozhodne neznamená že JSON je stom. Stom používate len ako rozhranie medzi vyššie spomenutou knižnicou a vaším kódom. Pritom ten parser/serializer je možné napísať aj tak že bude priamo validovať a mapovať na dátové typy. Potom na AST ani nenarazíte.
Libovolný platný JSON text lze interpretovat jako strom, tak jak jsem to popsal výše.
A tato interpretace je poměrně přirozená, proto je v nějaké formě dostupná prakticky v každé JSON knihovně.
Navíc je to přirozená interpretace i pro asociované technologie, jako třeba JSONPath. Výrazy v JSONPath jsou vlastně jenom instrukce, jak procházet strom nějakého JSON dokumentu. Nebo jq - velká část jq jazyka jsou taktéž jenom instrukce pro procházení stromu nějakého JSON dokumentu. Vizualizace JSON dokumentů (zrovna mě napadá třeba ve Firefoxu) jsou často ve formě stromu.
Stejně tak je to přirozená interpretace i pro člověka, viz třeba právě ten úvod v RFC 8259.
> Pritom ten parser/serializer je možné napísať aj tak že bude priamo validovať a mapovať na dátové typy.
To určitě. Ale ty datové typy, na které to mapuje, budou s největší pravděpodobností také tvořit strom.
Strom je špecifický typ grafu. Graf je dvojica množín (V, E), kde V je množina vrcholov a E je množina hrán (dvojíc vrcholov).
Triviálne prípady grafov - s prázdnou množinou vrcholov; s jednoprvkovou množinou vrcholov - sú stále platné grafy.
Stromová interpretácia JSONu "null" je jednoprvkový strom s koreňom null.
Jen malý vzkaz autorovi: asi by bylo velmi vhodné se vyhýbat podivným
novotvarům otrocky překrucovaným z angličtiny, nejspíš v zájmu jakési
rádobyodbornosti sdělení. Zde jde o výraz "konkatenace" (místo 'zřetězení',
popř. prostě 'spojení'). Podobně např. místo příšerné "edukace" lépe a
přirozeněji 'vzdělávání'. Oba zmíněné výrazy sice alibisticky uvádí ÚJČ AV ČR
na svém webu https://prirucka.ujc.cas.cz, ale ne každý jim musí rozumět a
pro českého rodilého mluvčího znějí hrůzně. Díky za pozornost a pochopení.
Autor o RFC 8259: Úvod dokonce definuje abstraktní představu JSON dokumentu, aniž by kdekoliv zmínil textovou reprezentaci.
První věta úvodu RFC 8259: JavaScript Object Notation (JSON) is a text format for the serialization of structured data.
RFC 8259 nerozlišuje JSON a JSON text, jak autor tvrdí. Ani nemůže, protože JSON je textový formát pro reprezentaci datových struktur JavaScriptu. Takže to první je JSON dokument a to druhé je obrázek datových struktur, které ten JSON dokument reprezentuje.
V tom úvodu RFC 8259 mi jde hlavně o to, že je tam část, která popisuje sémantiku JSON dokumentů, ne gramatiku.
Např. an object is an unordered collection of zero or more name/value pairs
popisuje jakýsi mentální model, jak na objekt nahlížet. Neříká nic o složených závorkách, uvozovkách a dvojtečkách.
Pro text, který ta gramatika v RFC 8259 popisuje, pak RFC 8259 konzistentně používá termín JSON text
.
Definice gramatiky JSON textu pak dost často mluví o reprezentaci, viz třeba tyto věty:
An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members).
An array structure is represented as square brackets surrounding zero or more values (or elements).
The representation of numbers is similar to that used in most programming languages.
The representation of strings is similar to conventions used in the C family of programming languages.
Tj. gramatika JSON textu se odkazuje na koncepty, které se zabývají sémantikou JSON dokumentů. A tím dává té textové reprezentaci nějaký význam.
Např. "a" je sekvence tří znaků (či Unicode codepointů, pokud chceme být trochu přesnější), která odpovídá gramatice JSON textu. Ale zároveň je to reprezentace řetězce s jedním znakem "a". Na druhou stranu "\u0061" je sice jiný JSON text, ale také je to reprezentace řetězce s jedním znakem "a".
To znamená, že reprezentovaná hodnota (nějaký JSON dokument) a její reprezentace (nějaký JSON text) jsou koncepčně odlišné věci. A RFC 8259 to zcela chápe a vskutku tyto dva koncepty rozlišuje.
Nutno poznamenat, že tyto koncepty nejsou příliš striktně pojmenované. Takže když někdo řekne "JSON", tak není úplně jasné, který z nich má na mysli. Možná má na mysli soubor plný JSON textu. A nebo možná má na mysli reprezentaci nějakého JSON dokumentu někde v paměti svého programu.
A nakonec ještě jedna drobnost:
JSON je textový formát pro reprezentaci datových struktur JavaScriptu.
To není tak úplně pravda. JSON je inspirovaný JavaScriptem a gramatikou některých jeho výrazů, ale JSON není schopný reprezentovat některé JavaScriptové hodnoty. Např. některá čísla (NaN, nekonečno, záporné nekonečno), funkce, či pole objektů pojmenované pomocí symbolů.
Vždyť to je už v názvu. Notation je notace aneb zápis. Neexistuje JSON dokument bez dokumentu. Existují nějaká data, která lze uložit do formátu JSON a až když je do něj uložíte, stane se z nich JSON.
První věta RFC 8259: JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.
První věta definice JSON v ECMA 404 (na kterou se RFC 8259 odkazuje): JSON is a text syntax that facilitates structured data interchange between all programming languages.
Ohledně sémantiky je ECMA 404 zcela explicitní:
The goal of this specification is only to define the syntax of valid JSON texts. Its intent is not to provide any semantics or interpretation of text conforming to that syntax.
"JSON je textový formát pro reprezentaci datových struktur JavaScriptu"
Je to tak. Mimochodem, Javascript (ECMAscript) od doby vytvoření JSON specifikace pokročil, např. už skoro 15 let lze zapsat čísla hexadecimálně, můžou začínat desetinou tečkou apod. Toto reflektuje JSON5, který dané vlastnosti přidává ke standartnímu JSONu. https://json5.org/
nic v zlom, ale napisat dva clanky o tom, ze vstupy treba validovat? a potom sa vam podari nieco taketo?
"Validace dat je samozřejmě důležitá. Ale účelem validace dat je zařídit, aby daná data dávala smysl a aby byla zpracovatelná.
...
Validace tedy nebude ta cesta, kterou se budeme dále vydávat. Než se ale vydáme tou správnou cestou, tak ještě jednou mírně odbočíme."
Co bude v tretom diele? urobite Cimrmanov krok stranou a vybalite validacnu schemu?