Názory k článku Manipulace se strukturovanými daty: sémantická manipulace s JSON dokumenty

ale v principu je json strom, ne?
nebo tam lze vytvaret odkazy a cykly, ted to zjistovat nebudu. pokud pominu ukecanost json, xml, ini a dalsich formatu, furt predstavuji stromovou strukturu, tak by se s tim jako se stromem melo pracovat.

JSON není strom. Popisuje datové struktury JavaScriptu - několik jednoduchých typů, objekty a pole. Korektní JSON je třeba tohle:

[116, 943, 234, 38793]

nebo

[ { "x": 1, "y": 2}, { "x": 5, "y": 7} ]

Asi se shodneme, že to nejsou stromy.

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.

To ze ty netusis jak vypada strom na tom ze to strom je nic nemeni.

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.

No v článku je spousta omáčky, ale o manipulaci s Json skoro nic. Jen vytvoření z dvou elementů a serializace.

Dále na JSON dokumentu není nic abstraktního.

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í.

Ja bych odporoval. Concatenate je ustaleny termin pro danou operaci ktery clovek potrebuje znat pro prakticke pouziti, proto me prijde lepsi rict "konkatenace" aby si to ctenar pak jednoduse spojil.

A proč rovnou nenapsat concatenate?

Souhlas, to je nejlepsi. Michani anglickych pojmu do ceskeho textu se ale puristum take nelibi.

9. 1. 2025, 13:22 editováno autorem komentáře

Přiznám se, že slovo "zřetězení" mi při psaní článku úplně vypadlo z hlavy. Ale je to rozhodně lepší slovo než "konkatenace".

Příště si na něj snad už vzpomenu.

K tomu C# - standardom bol skor Newtonsoft.Json, stale to vidiet na cislach stiahnuti balicku.

A tie dolare v kode - 1. au moje oci, 2. neda sa to skompilovat.

A taky

Console.Write­Line(JsonSeri­alizer.Seriali­ze(new {
id = $id,
name = $name
}));

lze zadat jednoduše tak:

Console.Write­Line(JsonSeri­alizer.Seriali­ze(new {
id,
name
}));

Ne tak úplně. `$id` a `$name jsou jenom zástupné symboly pro nějaký výraz, ne nutně pro proměnné jménem `id` a `name`.

Ale samozřejmě pokud by třeba místo `$name` byla proměnná jménem `name`, tak je zbytečné psát `name = name`.

Ta knihovna se reálně jmenuje Json.NET. Newtonsoft.Json je jenom identifikátor NuGet balíčku a název jmenného prostoru.

Co se dolarů týče, tak `$id` a `$name` v příkladech jenom zastupují nějaký, třeba řetězcový, výraz. Pokud si je za nějaký výraz nahradíte, tak ten kód zkompilovat jde.

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?