Fórum Root.cz
Hlavní témata => Software => Téma založeno: Kit 09. 07. 2018, 19:09:53
-
Když navrhuji vlastní formát XML, tak je přede mnou rozhodnutí, zda pro danou hodnotu použiji element či atribut. Z mého pohledu je to podobné rozhodování, jako v OOP umístění skalárních dat do samostatného objektu nebo do atributu. Oba přístupy mají něco do sebe (pro i proti) a výsledkem by měl být nějaký kompromis.
Narazil jsem však na jedno schéma, které se drží jednoho z extrémů, tedy všechno v elementech, ale nic v atributech:
<pluginRepository>
<id>snapshot-repo1.php-maven.org</id>
<name>PHP-Maven 2 Snapshot Repository</name>
<url>http://repos.php-maven.org/snapshots</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</pluginRepository>
Většina z vás jistě pozná úryvek z konfiguráku Mavenu.
Trochu jsem si s tím návrhem pohrál a udělal jsem z toho opačný extrém, tedy vše v atributech:
<pluginRepository
id="snapshot-repo1.php-maven.org"
name="PHP-Maven 2 Snapshot Repository"
url="http://repos.php-maven.org/snapshots"
releases="disabled"
snapshots="enabled"
/>
Informační obsah stejný, velikost a přehlednost rozdílná.
Pomiňme, že v Mavenu to jistě nikdo měnit nebude, ale takových dat a konfiguráků mi rukama prošlo už hodně. Některé byly ještě ukecanější a méně přehledné než první ukázka, např. klíč a hodnota v samostatných elementech uzavřené do dalšího nesémantického elementu. Jak navrhujete vlastní formáty XML? Proč dáváte přednost první variantě nebo proč druhé?
-
Používám jak elementy, tak atributy. Atributy jsou stručnější a přehlednější, ale můžeš u nich v budoucnu narazit. Základní pravidlo je: bude tu vždy ta hodnota jen jednou a bude atomická? Pokud je odpověď jednoznačné ano, tak není problém z toho udělat atribut. Pokud nevím nebo plánuji rozšíření (podpora více prvků nebo nějaké vnitřní členění, doplnění atributu k atributu), tak spíš element.
Ono není až taková tragédie udělat verzi formátu 2.0 a v ní přejít z atributů na elementy, ale to bych si nechával spíš na větší změny a při běžném vývoji se snažil jít spíš evoluční cestou (např. přibude nepovinný atribut).
Nacpat všechno do atributů může mít v některých případech racionální vysvětlení nebo nějakou myšlenku. Někteří lidé totiž kritizují XML za to, že je moc složité a umožňuje dva způsoby zápisu zanořených hodnot – a z tohoto důvodu ignorují atributy jakožto zbytečné (z teoretického pohledu skutečně zbytečné jsou) a snaží se používat jen podmnožinu z XML a dávat vše do elementů. Z teoretického a modelového pohledu to jednodušší je, z pohledu zápisu je to zase složitější. Osobně bych upřednostnil spíš ten praktičtější kompromis (elementy i atributy, které se lépe píší a čtou) než nějakou absolutní teoretickou čistotu formátu.
Většinou ale za tím žádná hluboká myšlenka nebude a je to spíš důsledek lenosti nebo ignorance. Ono špatně navržených nedomyšlených formátů postavených nad XML jsou spousty (což je i většina důvodů ke kritice XML – tzn. kritiku nezaslouží až tak XML jako takové, ale spíš některé formáty na něm postavené).
P.S. Určitě je lepší mít někde element, i když by stačil atribut, než mastit víc hodnot do jednoho atributu oddělených třeba čárkou nebo mezerou. Nebo taková zvěrstva jako atribut-1="" atribut-2="" atribut-2="" nebo dokonce „emulaci“ jmenných prostorů pomocí nějakých prefixů. Za taková zvěrstva by měl následovat krutý trest.
-
Primárně používám elementy. Mohou se opakovat, mohu do nich vkládat další elementy, můžu je zakomentovat atd. Atributy chápu jako něco, co chci jen přidat k nějakému elementu, ale samotné to nemá smysl – typicky při použití XML pro značkování textu. To, že se u ukončovacího tagu musí opakovat název elementu, bych vůbec neřešil – od toho přece máme editory.
-
A je to primárně formát anotující text (jako html) nebo formát pro serializaci dat?
-
W3Schools : XML Elements vs. Attributes
https://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp
IDM Developer Works : When to use elements versus attributes
https://www.ibm.com/developerworks/library/x-eleatt/index.html
happy reading :)
-
A je to primárně formát anotující text (jako html) nebo formát pro serializaci dat?
Tohle je část konfiguráku pro Maven, tedy formát pro serializaci dat, který by vývojář mohl chtít číst a případně modifikovat - jenom jako příklad. Uvažoval jsem nad tím, jaký by mělo smysl použití více než jednoho elementu id, name, url, releases a snapshots. Podle mne žádný. Už jsem předělal dost nepřehledných struktur XML popsaným způsobem. Zpravidla přitom zmizelo dost značek, které tam neměly co pohledávat.
U anotovaného textu je pravidlo, že když se odstraní značky, mělo by být zachováno sdělení. To však není tento případ.
Dnes se dost rozmohlo používání formátů JSON a YAML, často na úkor XML. Důvodem je zpravidla tvrzení, že XML zabírá víc místa a je méně přehledné. Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.
-
Používám jak elementy, tak atributy. Atributy jsou stručnější a přehlednější, ale můžeš u nich v budoucnu narazit. Základní pravidlo je: bude tu vždy ta hodnota jen jednou a bude atomická? Pokud je odpověď jednoznačné ano, tak není problém z toho udělat atribut. Pokud nevím nebo plánuji rozšíření (podpora více prvků nebo nějaké vnitřní členění, doplnění atributu k atributu), tak spíš element.
Toho jsem si vědom. Právě tím atributem bych rád zvýraznil, že ta hodnota smí být pouze jednou.
Pokud by však atribut byl například cena="42" a k tomu jednotka="CZK", tak by to už mohl být problém.
P.S. Určitě je lepší mít někde element, i když by stačil atribut, než mastit víc hodnot do jednoho atributu oddělených třeba čárkou nebo mezerou. Nebo taková zvěrstva jako atribut-1="" atribut-2="" atribut-2="" nebo dokonce „emulaci“ jmenných prostorů pomocí nějakých prefixů. Za taková zvěrstva by měl následovat krutý trest.
Setkal jsem se i s protipólem, tedy s elementy foto1, foto2, foto3. V nich byly elementy url a name. Hnus. Přitom se to dalo krásně umístit do tří elementů foto s atributy id, url a name.
-
W3Schools : XML Elements vs. Attributes
https://www.w3schools.com/xml/xml_dtd_el_vs_attr.asp
IDM Developer Works : When to use elements versus attributes
https://www.ibm.com/developerworks/library/x-eleatt/index.html
happy reading :)
Tohle už mám za sebou, spíš se ptám na osobní preference.
-
MÁM ŘEŠENÍ! Jako vždy 8)
Není to náhodou v konfigrácích Springu tak, že máš atribut "ref", napr "ref="mojeBeana"", ale druha moznost jak zadat ref je pres inner text?
To dava smysl. Tzn diky tomu si ty sam muzes rozhodnout, jestli pouzijes ref a nebo inner text popř. inner element. Kdyz mas obyc String, das do do ref. Kdyz mas nejakou vlastnost ve slozenych zavorkach, tj odkazuje se to na properies file, das to do inner text. A kdyz ma byt ref slozeny typ, das to jako inner element.
Ma to hlavu a patu, je to konzistentni.
-
Už s XML delší dobou nedělám (byl to jeden čas můj denní chléb) ale myslím že někteří předřečníci to vystihli správně. Koneckonců i ty názvy “atribut” a “element” napovídají…
“atribut” typicky jednoduchá nestrukturovaná hodnota (číslo, krátký string /label, tag/, výčtová hodnota), doslova “vlastnost elementu”.
“element” - plnotučná “zanořená” strukturovaná nebo “dlouhá (text)” věc.
Je to (dualita atribut × element, resp. atribut navíc k obecnému elementu) syntaktický cukr ale použit s rozumem data serializovaná do xml výrazně zpřehledňuje.
-
...Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.
Technologický dluh??? Tohle budete muset vysvětlit. A dokud nebude zcela jasně definovaný smysl atributu, tak to půjde těžko. Myslel jsem, že formát, do kterého se "jen nasypou data", je cílem.
-
...Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.
Technologický dluh??? Tohle budete muset vysvětlit. A dokud nebude zcela jasně definovaný smysl atributu, tak to půjde těžko. Myslel jsem, že formát, do kterého se "jen nasypou data", je cílem.
Vytrženo z kontextu formátů JSON a YAML, které jsou možná pohodlné, ale nejsou samopopisující. Kvůli nim vzniká ten technologický dluh.
-
...Problém je však podle mne v tom že ti vývojáři už neumí XML ani vhodně navrhnout a tak použijí formát, který ani moc navrhovat nemusí a do kterého vlastně jen nasypou data. Přitom si neuvědomují, že tím vzniká technologický dluh.
Technologický dluh??? Tohle budete muset vysvětlit. A dokud nebude zcela jasně definovaný smysl atributu, tak to půjde těžko. Myslel jsem, že formát, do kterého se "jen nasypou data", je cílem.
Samozřejmě, ze je to technologický dluh. Rychle zmaštěná aplikace sice ušetří nějaký čas na začátku, ale následně se ti to vrátí. Někteří vývojáři si bohužel neuvedomuji, že navrhnout formát není totéž jako vybrat knihovnu pro serializaci. Nebo, že mavrhnout API není totéž jako zpřístupnit pro vzdálené volání par metod pomoci nějaké technologie.
-
Už s XML delší dobou nedělám (byl to jeden čas můj denní chléb) ale myslím že někteří předřečníci to vystihli správně. Koneckonců i ty názvy “atribut” a “element” napovídají…
“atribut” typicky jednoduchá nestrukturovaná hodnota (číslo, krátký string /label, tag/, výčtová hodnota), doslova “vlastnost elementu”.
“element” - plnotučná “zanořená” strukturovaná nebo “dlouhá (text)” věc.
Je to (dualita atribut × element, resp. atribut navíc k obecnému elementu) syntaktický cukr ale použit s rozumem data serializovaná do xml výrazně zpřehledňuje.
U mne ten vývoj byl opačný. Nejprve se mi XML moc nelíbil kvůli ukecanosti. Hledal jsem řešení typu INI, které v některých aplikacích stále používám, i když je zanoření omezeno na dvě úrovně. Hodně se mi líbil YAML pro maximální stručnost, ale nevýhodou je menší rozšíření parserů a generátorů. Když je v něm chyba, tak se hodně blbě hledá. Potom JSON, který má skvělé vlastnosti pro komunikaci s Javascriptem a některými NoSQL databázemi.
Jenže ze všeho nejlepší zůstává stále XML, u kterého jsou vyřešeny problémy, kterými předchozí formáty trpí. Při správném návrhu je také dobře čitelný, je validovatelný a dá se zpracovávat standardními nástroji. Jen je poslední dobou vývojáři poněkud opomíjený.
-
Jenže ze všeho nejlepší zůstává stále XML, u kterého jsou vyřešeny problémy, kterými předchozí formáty trpí. Při správném návrhu je také dobře čitelný, je validovatelný a dá se zpracovávat standardními nástroji. Jen je poslední dobou vývojáři poněkud opomíjený.
No jo, jenže než na tohle většina lidí přijde, že to, co řeší s JSONem nebo YAML, má XML už dávno vyřešené, a že ty takzvané výhody JSONu nebo YAMLu jsou ve skutečnosti nevýhody…
Nejprve se mi XML moc nelíbil kvůli ukecanosti.
Tohle je zvláštní zcestná představa, kterou má ovšem spousta vývojářů – totiž že by jazyk (ať už programovací, formátovací nebo pro zápis strukturovaných dat) měl být maximálně stručný. Přitom si můžeme vzít za vzor přirozené jazyky, které přílišnou stručností rozhodně neoplývají. A to se lidský jazyk vyvinul z nějakých skřeků, takže se určitě rozvíjel od stručnosti směrem k rozvinutosti a redundanci. Už jenom tohle by mělo stačit k tomu, abychom si uvědomili, že určitá redundance v jazyce je pro člověka prospěšná (například proto, že nás při čtení utvrzuje v tom, že čteme správně).
-
Nejprve se mi XML moc nelíbil kvůli ukecanosti.
Tohle je zvláštní zcestná představa, kterou má ovšem spousta vývojářů – totiž že by jazyk (ať už programovací, formátovací nebo pro zápis strukturovaných dat) měl být maximálně stručný. Přitom si můžeme vzít za vzor přirozené jazyky, které přílišnou stručností rozhodně neoplývají. A to se lidský jazyk vyvinul z nějakých skřeků, takže se určitě rozvíjel od stručnosti směrem k rozvinutosti a redundanci. Už jenom tohle by mělo stačit k tomu, abychom si uvědomili, že určitá redundance v jazyce je pro člověka prospěšná (například proto, že nás při čtení utvrzuje v tom, že čteme správně).
Na tohle hodně doplatil XSLT. Na první pohled vypadá ukecaně, i když atributy používá. Když v něm však vytvořím nějakou šablonu, bývá stručnější než v jiných šablonovacích jazycích a také mnohem rychlejší. Jenže vývojářům se nelíbí.
-
Už s XML delší dobou nedělám (byl to jeden čas můj denní chléb) ale myslím že někteří předřečníci to vystihli správně. Koneckonců i ty názvy “atribut” a “element” napovídají…
“atribut” typicky jednoduchá nestrukturovaná hodnota (číslo, krátký string /label, tag/, výčtová hodnota), doslova “vlastnost elementu”.
“element” - plnotučná “zanořená” strukturovaná nebo “dlouhá (text)” věc.
Je to (dualita atribut × element, resp. atribut navíc k obecnému elementu) syntaktický cukr ale použit s rozumem data serializovaná do xml výrazně zpřehledňuje.
U mne ten vývoj byl opačný....
Jenže ze všeho nejlepší zůstává stále XML, u kterého jsou vyřešeny problémy, kterými předchozí formáty trpí. Při správném návrhu je také dobře čitelný, je validovatelný a dá se zpracovávat standardními nástroji. Jen je poslední dobou vývojáři poněkud opomíjený.
S tímhle souhlasím... s XML jsem přestal dělat ne proto že se mi nelíbil, ale proto že jsem se začal zabývat jiným typem programování... pracovat s JSONem což občas musím protože je dneska takový de-facto industry standard je pro mě po té zkušenosti s XML/XSLT/XProc utrpením.
-
Vytrženo z kontextu formátů JSON a YAML, které jsou možná pohodlné, ale nejsou samopopisující. Kvůli nim vzniká ten technologický dluh.
YAML neznám. V JSONu má každá položka název (je to adresář), co by to mělo mít navíc?
-
Samozřejmě, ze je to technologický dluh. Rychle zmaštěná aplikace sice ušetří nějaký čas na začátku, ale následně se ti to vrátí. Někteří vývojáři si bohužel neuvedomuji, že navrhnout formát není totéž jako vybrat knihovnu pro serializaci. Nebo, že mavrhnout API není totéž jako zpřístupnit pro vzdálené volání par metod pomoci nějaké technologie.
To nerozporuju. Mě zajímá, jak vznikne tech. dluh, když místo XML použiju JSON.
-
No jo, jenže než na tohle většina lidí přijde, že to, co řeší s JSONem nebo YAML, má XML už dávno vyřešené, a že ty takzvané výhody JSONu nebo YAMLu jsou ve skutečnosti nevýhody…
Které to jsou? Neznám to, nechám se poučit (třeba to pak nebudu muset zjišťovat sám).
Tohle je zvláštní zcestná představa, kterou má ovšem spousta vývojářů – totiž že by jazyk (ať už programovací, formátovací nebo pro zápis strukturovaných dat) měl být maximálně stručný. Přitom si můžeme vzít za vzor přirozené jazyky, které přílišnou stručností rozhodně neoplývají. A to se lidský jazyk vyvinul z nějakých skřeků, takže se určitě rozvíjel od stručnosti směrem k rozvinutosti a redundanci. Už jenom tohle by mělo stačit k tomu, abychom si uvědomili, že určitá redundance v jazyce je pro člověka prospěšná (například proto, že nás při čtení utvrzuje v tom, že čteme správně).
Tak do této úvahy se vůbec nepouštějte, to je velmi složité téma, prosté srovnání zde z důvodu rozdílných podstat a účelů jazyků nemůže fungovat.
-
Vytrženo z kontextu formátů JSON a YAML, které jsou možná pohodlné, ale nejsou samopopisující. Kvůli nim vzniká ten technologický dluh.
YAML neznám. V JSONu má každá položka název (je to adresář), co by to mělo mít navíc?
Validace, komentáře, příkazy pro zpracování, různé znakové sady, čitelný český text, sada obecných nástrojů,...
-
No jo, jenže než na tohle většina lidí přijde, že to, co řeší s JSONem nebo YAML, má XML už dávno vyřešené, a že ty takzvané výhody JSONu nebo YAMLu jsou ve skutečnosti nevýhody…
Které to jsou? Neznám to, nechám se poučit (třeba to pak nebudu muset zjišťovat sám).
Už jsem některé jmenoval výše. Už hodně vývojářů si pobrečelo, že JSON nemá možnost komentářů. Jiné datové typy než int nebo string se musí předem serializovat. Příkazy pro zpracování jsou věcí neznámou. Možnost definování entit nulová. Čeština se v tom nedá číst. Absence schéma. Je toho snad málo?
-
Tak do této úvahy se vůbec nepouštějte, to je velmi složité téma, prosté srovnání zde z důvodu rozdílných podstat a účelů jazyků nemůže fungovat.
Proč by to srovnání nemohlo fungovat? Proč někteří vzývají stručnost u programovacích a podobných jazyků? Aby toho programátor mohl číst a psát co nejméně, aby se nemusel zabývat balastem. Psaná můžeme zanedbat, protože je za prvé méně časté, za druhé zrovna pro tyhle technické jazyky máme perfektní IDE, která ten „balast“ umí generovat sama. Takže zbývá čtení. A v čem se liší čtení programu od čtení novinového článku nebo diplomky, že by ta redundance u přirozených jazyků byla přínosná, ale u technických jazyků byla naopak škodlivá?
-
A v čem se liší čtení programu od čtení novinového článku nebo diplomky, že by ta redundance u přirozených jazyků byla přínosná, ale u technických jazyků byla naopak škodlivá?
Je to vidět na dříve vytvořených jazycích COBOL, SQL nebo třeba Pascal. Zejména ten první byl řádně ukecaný. Výsledek? Dnes už se v něm programuje okrajově. Když jsem se učil Pascal, tak mi vadila zejména slova begin a end. Proč? Musela se psát pořád dokola, dokonce i tam, kde to nebylo povinné. Výsledkem byla a je horší čitelnost a snižující se obliba Pascalu. Jazyk C přišel s elegantními {} a všichni jásali, že se to dobře píše i čte. PHP také používalo if (...): ... else: ... endif. Postupně se přešlo na C-like syntaxi.
Minimalisté přišli s jazykem Python a formátem YAML. Výsledkem je naopak odpor vývojářů zvyklých na {}. Podobně i Lisp, který těch závorek nemá víc než ostatní jazyky, si nezískal mnoho příznivců. Přitom by mohl sloužit pro různé konfiguráky i pro výměnu dat mnohem lépe než třeba JSON.
Ideál je tedy někde uprostřed. XML bez atributů má na pohled více zbytečného textu než XML s atributy. Tam, kde bychom stejně dali u zavírací závorky komenář, má koncovou značku. Zbývá jen udělat vhodný návrh, který maximalizuje čitelnost pro lidi i stroje.
-
Je to vidět na dříve vytvořených jazycích COBOL, SQL nebo třeba Pascal. Zejména ten první byl řádně ukecaný. Výsledek? Dnes už se v něm programuje okrajově. Když jsem se učil Pascal, tak mi vadila zejména slova begin a end. Proč? Musela se psát pořád dokola, dokonce i tam, kde to nebylo povinné. Výsledkem byla a je horší čitelnost a snižující se obliba Pascalu.
Nevidím tu souvislost, proč by zrovna ukecanost měla být důvodem, proč se ty jazyky nepoužívají. Třeba Java je podle mne o něco ukecanější, než ObjectPascal/Delphi, ale okrajová není.
Minimalisté přišli s jazykem Python a formátem YAML.
Idea, že když už odsazujeme kvůli čitelnosti, může se to použít i pro strukturování kódu, je hezká, ale podle mne troskotá právě na tom, že lidé chtějí odsazení jako tu balastní informaci navíc, pro lepší čtení a pro kontrolu, ale nechtějí to jako primární a jediný zdroj informací o struktuře. Určitá míra ukecanosti je prostě přínosná.
Ideál je tedy někde uprostřed.
Navíc má každý ten ideál trochu někde jinde. Každopádně snažit se o co největší stručnost je špatná cesta. Ostatně to platí i u algoritmů – pokud není nutné kód nějak optimalizovat, je lepší delší ale srozumitelnější kód, než nějaký oneliner.
Zbývá jen udělat vhodný návrh, který maximalizuje čitelnost pro lidi i stroje.
Vhodný návrh čeho? XML už navrženo bylo :-)
-
Zbývá jen udělat vhodný návrh, který maximalizuje čitelnost pro lidi i stroje.
Vhodný návrh čeho? XML už navrženo bylo :-)
XML je formát, který nemá žádnou značku, ale má metodiku, jak si vlastní značky definovat. To je cílem toho návrhu struktury souboru XML, nejlépe pomocí XSD nebo Relax NG.
-
Samozřejmě, ze je to technologický dluh. Rychle zmaštěná aplikace sice ušetří nějaký čas na začátku, ale následně se ti to vrátí. Někteří vývojáři si bohužel neuvedomuji, že navrhnout formát není totéž jako vybrat knihovnu pro serializaci. Nebo, že mavrhnout API není totéž jako zpřístupnit pro vzdálené volání par metod pomoci nějaké technologie.
To nerozporuju. Mě zajímá, jak vznikne tech. dluh, když místo XML použiju JSON.
Už třeba takový detail, že JSON neumí komentáře. Často vídám testery nebo lidi, kteří si potřebují provolat nějakou REST/JSON službu – trpí tím, že si nemůžou část požadavku zakomentovat. Musí to vyjmou do schránky, napsat něco jiného, ve schránce se jim to ztrácí, tak to musí vykopírovat do jiného programu. To je práce jak za krále Klacka. Možná by mohli nastoupit někam do nevolnictví. JSON prostě brzdí vývoj a testování.
Kdyby to bylo v XML, tak snadno část zakomentují a můžou zkoušet posílat alternativní požadavky nebo si tam dopsat poznámku, vysvětlivku. Pro konfiguráky to platí dvojnásob.
Pak tam taky chybí jmenné prostory, takže ten formát není rozšiřitelný. Jsou jakési pokusy, jak to tam dohackovat, ale je to takové drbání se levou rukou na pravém uchu.
Hodně velký problém byl (a často stále je) chybějící infrastruktura – editory, validátory, schéma, dotazovací jazyk, transformační jazyk… něco z toho se jim už podařilo dovyvinout, znovu-vynalézt kolo, ale celé roky znamenalo použití JSONu vracet se někam do středověku… a zbytečně.
Někdy je taky problém s tím, že nezáleží na pořadí klíčů, takže musíš načíst vše a pak se teprve můžeš rozhodovat, jak jednotlivé hodnoty interpretovat. Na to narazíš, když chceš udělat nějaký pružnější/variabilnější datový model, kde můžeš mít různé typy (např. dědičnost). Pak se to musí všelijak obcházet přes pole (která zachovají pořadí, ale je to hnusné), nebo natáhnout vše do paměti a pak teprve zpracovat, což zase brání proudovému zpracování dlouhých dat. Nakonec by si člověk musel napsat vlastní parser a generátor.
Našlo by se toho víc, ale jako příklad to snad stačí.
-
No jo, jenže než na tohle většina lidí přijde, že to, co řeší s JSONem nebo YAML, má XML už dávno vyřešené, a že ty takzvané výhody JSONu nebo YAMLu jsou ve skutečnosti nevýhody…
Které to jsou? Neznám to, nechám se poučit (třeba to pak nebudu muset zjišťovat sám).
Už jsem některé jmenoval výše. Už hodně vývojářů si pobrečelo, že JSON nemá možnost komentářů. Jiné datové typy než int nebo string se musí předem serializovat. Příkazy pro zpracování jsou věcí neznámou. Možnost definování entit nulová. Čeština se v tom nedá číst. Absence schéma. Je toho snad málo?
Možná by bylo dobré se nevyjadřovat k věcem, o kterých nic nevíte nebo jim nerozumíte.
viz třeba:
"čeština se v tom nedá čít" ... string - any unicode character except " and \
absence schema: http://json-schema.org/
-
A v čem se liší čtení programu od čtení novinového článku nebo diplomky, že by ta redundance u přirozených jazyků byla přínosná, ale u technických jazyků byla naopak škodlivá?
Je to vidět na dříve vytvořených jazycích COBOL, SQL nebo třeba Pascal. Zejména ten první byl řádně ukecaný. Výsledek? Dnes už se v něm programuje okrajově. Když jsem se učil Pascal, tak mi vadila zejména slova begin a end. Proč? Musela se psát pořád dokola, dokonce i tam, kde to nebylo povinné. Výsledkem byla a je horší čitelnost a snižující se obliba Pascalu. Jazyk C přišel s elegantními {} a všichni jásali, že se to dobře píše i čte. PHP také používalo if (...): ... else: ... endif. Postupně se přešlo na C-like syntaxi.
Minimalisté přišli s jazykem Python a formátem YAML. Výsledkem je naopak odpor vývojářů zvyklých na {}. Podobně i Lisp, který těch závorek nemá víc než ostatní jazyky, si nezískal mnoho příznivců. Přitom by mohl sloužit pro různé konfiguráky i pro výměnu dat mnohem lépe než třeba JSON.
Ideál je tedy někde uprostřed. XML bez atributů má na pohled více zbytečného textu než XML s atributy. Tam, kde bychom stejně dali u zavírací závorky komenář, má koncovou značku. Zbývá jen udělat vhodný návrh, který maximalizuje čitelnost pro lidi i stroje.
Stačilo jen napsat "miluji XML". Zbytek je jen směs žvástů, polopravd a nesmyslů.
-
Samozřejmě, ze je to technologický dluh. Rychle zmaštěná aplikace sice ušetří nějaký čas na začátku, ale následně se ti to vrátí. Někteří vývojáři si bohužel neuvedomuji, že navrhnout formát není totéž jako vybrat knihovnu pro serializaci. Nebo, že mavrhnout API není totéž jako zpřístupnit pro vzdálené volání par metod pomoci nějaké technologie.
To nerozporuju. Mě zajímá, jak vznikne tech. dluh, když místo XML použiju JSON.
Už třeba takový detail, že JSON neumí komentáře. Často vídám testery nebo lidi, kteří si potřebují provolat nějakou REST/JSON službu – trpí tím, že si nemůžou část požadavku zakomentovat. Musí to vyjmou do schránky, napsat něco jiného, ve schránce se jim to ztrácí, tak to musí vykopírovat do jiného programu. To je práce jak za krále Klacka. Možná by mohli nastoupit někam do nevolnictví. JSON prostě brzdí vývoj a testování.
Kdyby to bylo v XML, tak snadno část zakomentují a můžou zkoušet posílat alternativní požadavky nebo si tam dopsat poznámku, vysvětlivku. Pro konfiguráky to platí dvojnásob.
Pak tam taky chybí jmenné prostory, takže ten formát není rozšiřitelný. Jsou jakési pokusy, jak to tam dohackovat, ale je to takové drbání se levou rukou na pravém uchu.
Hodně velký problém byl (a často stále je) chybějící infrastruktura – editory, validátory, schéma, dotazovací jazyk, transformační jazyk… něco z toho se jim už podařilo dovyvinout, znovu-vynalézt kolo, ale celé roky znamenalo použití JSONu vracet se někam do středověku… a zbytečně.
Někdy je taky problém s tím, že nezáleží na pořadí klíčů, takže musíš načíst vše a pak se teprve můžeš rozhodovat, jak jednotlivé hodnoty interpretovat. Na to narazíš, když chceš udělat nějaký pružnější/variabilnější datový model, kde můžeš mít různé typy (např. dědičnost). Pak se to musí všelijak obcházet přes pole (která zachovají pořadí, ale je to hnusné), nebo natáhnout vše do paměti a pak teprve zpracovat, což zase brání proudovému zpracování dlouhých dat. Nakonec by si člověk musel napsat vlastní parser a generátor.
Našlo by se toho víc, ale jako příklad to snad stačí.
Takže veškerý dluh je absence komentářů. To vám brzo došly argumenty. Pokud požadujete komentáře, použijte JSON5.
-
viz třeba:
"čeština se v tom nedá čít" ... string - any unicode character except " and \
Zajímavé je, že když jsem napsal do JSONu český text, tak mi to parser odmítl.
-
Pak tam taky chybí jmenné prostory, takže ten formát není rozšiřitelný. Jsou jakési pokusy, jak to tam dohackovat, ale je to takové drbání se levou rukou na pravém uchu.
Hodně velký problém byl (a často stále je) chybějící infrastruktura – editory, validátory, schéma, dotazovací jazyk, transformační jazyk… něco z toho se jim už podařilo dovyvinout, znovu-vynalézt kolo, ale celé roky znamenalo použití JSONu vracet se někam do středověku… a zbytečně.
Někdy je taky problém s tím, že nezáleží na pořadí klíčů, takže musíš načíst vše a pak se teprve můžeš rozhodovat, jak jednotlivé hodnoty interpretovat. Na to narazíš, když chceš udělat nějaký pružnější/variabilnější datový model, kde můžeš mít různé typy (např. dědičnost). Pak se to musí všelijak obcházet přes pole (která zachovají pořadí, ale je to hnusné), nebo natáhnout vše do paměti a pak teprve zpracovat, což zase brání proudovému zpracování dlouhých dat. Nakonec by si člověk musel napsat vlastní parser a generátor.
Našlo by se toho víc, ale jako příklad to snad stačí.
Takže veškerý dluh je absence komentářů. To vám brzo došly argumenty. Pokud požadujete komentáře, použijte JSON5.
A co ty jmenné prostory a chybějící infrastruktura? Já vím, JSON je nemá, protože je nepotřebuje...
-
Stačilo jen napsat "miluji XML". Zbytek je jen směs žvástů, polopravd a nesmyslů.
No já bych to viděl obráceně...
Co mně na JSONu chybí nejvíc je nějaký standardní query language (na způsob Xpath)... transformace (ala XSLT) by se také nejednou hodně hodily.
-
Já vím, JSON je nemá, protože je nepotřebuje...
No ano. JSON se ujal právě proto, že je jednoduchý. XML je na většinu problémů zbytečně překombinovaná parní mlátička.
Jmenné prostory, transformační a dotazovací jazyky a podobně jsou celkem zbytečné, pokud potřebuju serializovat nebo deserializovat nějakou relativně jednoduchou datovou strukturu.
-
Já vím, JSON je nemá, protože je nepotřebuje...
No ano. JSON se ujal právě proto, že je jednoduchý. XML je na většinu problémů zbytečně překombinovaná parní mlátička.
Jmenné prostory, transformační a dotazovací jazyky a podobně jsou celkem zbytečné, pokud potřebuju serializovat nebo deserializovat nějakou relativně jednoduchou datovou strukturu.
XML se sá používat stejně jednoduchým způsobem jako JSON. Tedy bez jmenných prostorů, transformačních a dotazovacích jazyků. Pokud se z jednoduché datové struktury časem stane složitější, tak s tím nená problém. Dokonce ani není problém se specifikací a zveřejněním takové datové struktury pro potřebu výměny dat mezi subjekty. Vše je standardizováno, není povinné ani složité to použít.
Když se vrátím k příkladu na začátku, tak v JSONu by to mohlo vypadat asi takto:
{
"pluginRepository": {
"id": "snapshot-repo1.php-maven.org",
"name": "PHP-Maven 2 Snapshot Repository",
"url": "http://repos.php-maven.org/snapshots",
"releases": {
"enabled": "false"
},
"snapshots": {
"enabled": "true"
}
}
}
Vypadá to možná trochu lépe, ale jen do doby, než přidám třeba druhé URL. Parser JSON musí v tom případě počítat s oběma variantami, zatímco parseru XML by to bylo jedno. Se svým zjednodušeným řešením XML bych samozřejmě také narazil.
-
Vypadá to možná trochu lépe, ale jen do doby, než přidám třeba druhé URL. Parser JSON musí v tom případě počítat s oběma variantami, zatímco parseru XML by to bylo jedno. Se svým zjednodušeným řešením XML bych samozřejmě také narazil.
Parser jsonu ale nenarazí. Respektive narazí úplně stejně jako ten xml. Pokud jedno url nahradím seznamem url, tak každý parser (který znám) vrátí správný DOM objekt pro seznam. Stejně jako u xml si na tom vyláme zuby až kód, který zpracovává ten DOM.
-
Jmenné prostory, transformační a dotazovací jazyky a podobně jsou celkem zbytečné, pokud potřebuju serializovat nebo deserializovat nějakou relativně jednoduchou datovou strukturu.
Jenže to je šetření na špatném místě. Třeba transformační a dotazovací jazyky mne nic nestojí, jsou vedle původního standardu a když nechci, vůbec je používat nemusím. Jenže i když chci serializovat nebo deserializovat jednoduchou datovou strukturu, jakmile opustím školní příklady, zjistím, že bych strukturu serializovanou jedním způsobem potřeboval deserializovat jinde, kde se očekává mírně odlišný formát, nebo potřebuju někde jenom ručně ověřit, kolik tam je vlastně položek atd. A najednou se mi hodí, že ty transformační a dotazovací jazyky mám po ruce a můžu je hned použít.
Ona ostatně není náhoda, že i pro JSON dotazovací jazyky existují, a myslím, že je snaha vytvořit i nějaký transformační jazyk. Takže všechno, co je na XML údajně zbytečné, se k JSONu postupně doplňuje. Akorát je trochu smutné, že JSON je vlastně takové „XML znovu a hůře“.
-
viz třeba:
"čeština se v tom nedá čít" ... string - any unicode character except " and \
Zajímavé je, že když jsem napsal do JSONu český text, tak mi to parser odmítl.
Mlčeti zlato. Těžko říct, co za sračku používáte. Asi PHP.
Třeba se poučíte zde: https://stackoverflow.com/questions/7381900/php-decoding-and-encoding-json-with-unicode-characters
Je to více než 6 let staré.
-
Jenže to je šetření na špatném místě.
Co je a není šetření na špatném místě dost závisí na kontextu.
Třeba transformační a dotazovací jazyky mne nic nestojí, jsou vedle původního standardu a když nechci, vůbec je používat nemusím.
Ale stojí. Ta cena je rozpuštěná v celkové nešikovnosti a ukecanosti xml. A taky třeba ve velikosti knihoven, které jsou na to xml potřeba.
Jenže i když chci serializovat nebo deserializovat jednoduchou datovou strukturu, jakmile opustím školní příklady, zjistím, že bych strukturu serializovanou jedním způsobem potřeboval deserializovat jinde, kde se očekává mírně odlišný formát, nebo potřebuju někde jenom ručně ověřit, kolik tam je vlastně položek atd. A najednou se mi hodí, že ty transformační a dotazovací jazyky mám po ruce a můžu je hned použít.
Jak jsem psal, záleží na kontextu. V práci nedělám školní příklady, ale nic ze zmíněného jsem za poslední roky nepotřeboval. I kdyby to bylo úplně zadarmo, tak je mi to k ničemu.
Ona ostatně není náhoda, že i pro JSON dotazovací jazyky existují, a myslím, že je snaha vytvořit i nějaký transformační jazyk. Takže všechno, co je na XML údajně zbytečné, se k JSONu postupně doplňuje. Akorát je trochu smutné, že JSON je vlastně takové „XML znovu a hůře“.
Ono to není "XML znovu a hůře". Ono je to "něco jako XML s dost odlišnými kompromisy". A ujalo se právě proto, že ve spoustě případů jsou výhody xml bezcenné a zůstává jen lehký ale všudypřítomný opruz. A že se občas ukáže, že byly počáteční analýzy mimo, je bohužel smutná realita vývoje.
-
Ta cena je rozpuštěná v celkové nešikovnosti a ukecanosti xml.
Jak už bylo napsáno, XML není ukecané.
A taky třeba ve velikosti knihoven, které jsou na to xml potřeba.
Nikoli. Pro transformace nebo dotazování jsou jiné knihovny, než pro parsování XML. Složitost XML parserů je způsobená DTD a uživatelskými entitami, které stejně nikdo nepoužívá. Takže by úplně stačilo vydat standard XML 1.2, který tohle vyhodí, kodifikovalo by se tak to, jak se XML reálně používá, a nemuseli se vymýšlet hlouposti jako JSON.
Jak jsem psal, záleží na kontextu. V práci nedělám školní příklady, ale nic ze zmíněného jsem za poslední roky nepotřeboval. I kdyby to bylo úplně zadarmo, tak je mi to k ničemu.
Já to potřebuji tak v polovině případů práce s JSON. Spíš bych řekl, že vás ani nenapadlo, že byste mohl něco takového potřebovat. Že byste třeba informace z JSON souboru mohl získat jednoduchým dotazem, než abyste něco zjišťoval ručně.
Ono to není "XML znovu a hůře".
Bohužel je. Opravdu špatně je na XML jen zmiňované DTD spolu s uživatelskými entitami, a odpůrci XML ani netuší, že něco takového existuje, takže to nemohou kritizovat. Jinak se do JSONu postupně doplňuje vše, co už XML dávno má – pokud je to možné. A když to není možné, jako ty komentáře, začne se vymýšlet nějaký JSON5.
Ono je to "něco jako XML s dost odlišnými kompromisy".
Mohl byste nějaký z těch odlišných kompromisů popsat? Zajímala by mne jediná výhoda JSONu oproti XML. Jaká je výhoda absence komentářů? Jaká je výhoda toho, že se teprve po letech doplňují jazyky pro schémata nebo dotazování, přičemž stále nejsou běžnou součástí nástrojů pro JSON? Jaká je výhoda absence jmenných prostorů?
A ujalo se právě proto, že ve spoustě případů jsou výhody xml bezcenné a zůstává jen lehký ale všudypřítomný opruz.
Pokaždé, když dělám s JSONem, připadám si, jak kdyby mi chyběly obě ruce. Pro někoho, kdo se narodil už bez rukou, mohou opravdu ruce připadat bezcenné. Ale není to tak. A ten „lehký ale všudypřítomný opruz“ je co přesně? Že vám editor musí doplnit název koncového tagu, a XML se pak mnohem lépe čte?
A že se občas ukáže, že byly počáteční analýzy mimo, je bohužel smutná realita vývoje.
Smutná realita v tomto případě je, že jsme tu měli docela dobře fungující XML s ekosystémem, který se dále zlepšoval, a místo toho, aby se odpárala ta jedna nepoužívaná ošklivá vlastnost XML, přišlo se s novým formátem, který měl být údajně jednodušší, ale ve skutečnosti je až tak jednoduchý, až je hloupý. A teď se u tohoto nového formátu s patnáctiletým zpožděním opakuje vynalézání toho, co se vynalezlo u XML. Se stejnými chybami jako u XML a navíc na horším podvozku.
Mimochodem, je zajímavé, že přesně to, co JSON vytýká XML, začali někteří vytýkat JSONu a vytvořili YAML. Nadějné je akorát to, že ty formáty jako JSON a YAML vznikají stále častěji a vzájemně se tlučou, zatímco XML vedle nich stabilně trvá. A má slušné XSD na definici schémat, výborné XSLT 3.0 na transformace, zatím nedoceněné XQuery na dotazování…
-
Kdyz si nasadim javove bryle tak asi i souhlasim.
Ale nekdo kdo dela v javasciptu muze mit jiny nazor(na co parsery, dotazovani, knihovny... kdyz je to prece rovnou objekt )
Jinak samozrejme cokoliv jineho nez edn nema smysl ;)
-
Kdyz si nasadim javove bryle tak asi i souhlasim.
Ale nekdo kdo dela v javasciptu muze mit jiny nazor(na co parsery, dotazovani, knihovny... kdyz je to prece rovnou objekt )
Jinak samozrejme cokoliv jineho nez edn nema smysl ;)
JSON má velký význam pro Javascript, to tady nikdo nepopírá. Ovšem jako obecný formát pro výměnu dat je použitelný jen s obtížemi. XML je naproti tomu možné použít, kdykoli chci někomu poslat nějaká strukturovaná data. Proto je také mnohem rozšířenější.
-
Ale nekdo kdo dela v javasciptu muze mit jiny nazor(na co parsery, dotazovani, knihovny... kdyz je to prece rovnou objekt )
Že je to „přece rovnou objekt“ je obrovská bezpečnostní díra a snad už to tak nikdo nepoužívá. I v tom JavaScriptu bylo potřeba napsat na JSON parser – a mimochodem prohlížeče měly z JavaScriptu dostupný XML parser dříve než JSON parser. Že je teď v prohlížečích podpora pro JSON lepší než podpora XML je pravda, ale kvůli tomu nebylo potřeba vytvářet nový formát. Ale je pravda, že zrovna webový svět nenávidí XML opravdu fest a neváhá kvůli tomu dělat některé pitomosti i opakovaně. Takže HTML5 musí mít samozřejmě svou vlastní serializaci, která je hodně podobná XML, ale XML to není. A aby dokázali, že jmenné prostory fakt nepotřebují, vymysleli nejdřív data-atributy, potom vložení SVG a MathML přímo do HTML5 standardu, a nejnověji webové komponenty. Ale ng- je určitě aspoň o 376 % lepší zápis než ng:.
-
I v tom JavaScriptu bylo potřeba napsat na JSON parser – a mimochodem prohlížeče měly z JavaScriptu dostupný XML parser dříve než JSON parser.
Proto také nepoužíváme zkratku AJAJ, ale AJAX.
-
Ale nekdo kdo dela v javasciptu muze mit jiny nazor(na co parsery, dotazovani, knihovny... kdyz je to prece rovnou objekt )
Že je to „přece rovnou objekt“ je obrovská bezpečnostní díra a snad už to tak nikdo nepoužívá. I v tom JavaScriptu bylo potřeba napsat na JSON parser – a mimochodem prohlížeče měly z JavaScriptu dostupný XML parser dříve než JSON parser. Že je teď v prohlížečích podpora pro JSON lepší než podpora XML je pravda, ale kvůli tomu nebylo potřeba vytvářet nový formát. Ale je pravda, že zrovna webový svět nenávidí XML opravdu fest a neváhá kvůli tomu dělat některé pitomosti i opakovaně. Takže HTML5 musí mít samozřejmě svou vlastní serializaci, která je hodně podobná XML, ale XML to není. A aby dokázali, že jmenné prostory fakt nepotřebují, vymysleli nejdřív data-atributy, potom vložení SVG a MathML přímo do HTML5 standardu, a nejnověji webové komponenty. Ale ng- je určitě aspoň o 376 % lepší zápis než ng:.
Ten JSON parser je ale prece sanity check + eval.
A kdy meli prohlizece podporu eval?
-
Ten JSON parser je ale prece sanity check + eval.
To by byla ta nejhloupější možná implementace. Protože ten sanity check by v sobě musel obsahovat parser JavaScriptu. Pořád jednodušší je parsovat JSON než JavaScript.
-
Ten JSON parser je ale prece sanity check + eval.
To by byla ta nejhloupější možná implementace. Protože ten sanity check by v sobě musel obsahovat parser JavaScriptu. Pořád jednodušší je parsovat JSON než JavaScript.
A nejaky priklad kde se to dela jinak by nebyl?
Nerikam, ze neni, jen o tom nevim.
-
A nejaky priklad kde se to dela jinak by nebyl?
Nerikam, ze neni, jen o tom nevim.
parseJSON. Kod to nespusti, musi to byt striktne odpovidajici JSON gramatice, tzn.striktni ppdmmozina JS zapisu struktur.
-
Ta cena je rozpuštěná v celkové nešikovnosti a ukecanosti xml.
Jak už bylo napsáno, XML není ukecané.
Napsáno tu bylo spousta věcí. Ale když se podívám na nějaké testy https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml (https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml) nebo https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity (https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity) tak to tak opravdu nevypadá.
Ono se stačí podívat na svg. Velké kusy toho formátu vlastně nejsou xml, ale stringy s vlastním výrazně jednodušším formátem. Přepsat to do xml by i při použití jednoznakových elementů strašně nabobtnalo. Seznamy v JSONu jsou daleko kompaktnější.
Já netvrdím, že XML je vždycky bloat. Ve spoustě případů ta ukecanost nevadí. Ale tvrdit, že ukecané není, je fakt síla.
A taky třeba ve velikosti knihoven, které jsou na to xml potřeba.
Nikoli. Pro transformace nebo dotazování jsou jiné knihovny, než pro parsování XML. Složitost XML parserů je způsobená DTD a uživatelskými entitami, které stejně nikdo nepoužívá. Takže by úplně stačilo vydat standard XML 1.2, který tohle vyhodí, kodifikovalo by se tak to, jak se XML reálně používá, a nemuseli se vymýšlet hlouposti jako JSON.
Ano, jeden z problémů XML je, že je to moloch. To, že se velký kus toho molochu nepoužívá znamená akorát, že je to nepovedený moloch. Ano, kdybychom měli XML bez nevýhod XML, tak bychom JSON možná nepotřebovali. Akorát že s tím XML 1.2 zatím nikdo nepřišel a za vlhké sny mi nikdo nezaplatí. ::)
Základní vlastnost standardů je, že se do nich jednoduše přidává, ale strašně blbě se cokoliv mění, nebo vyhazuje. Kdyby přišlo XML 1.2, tak pravděpodobně dopadne jako Python 3.
Jak jsem psal, záleží na kontextu. V práci nedělám školní příklady, ale nic ze zmíněného jsem za poslední roky nepotřeboval. I kdyby to bylo úplně zadarmo, tak je mi to k ničemu.
Já to potřebuji tak v polovině případů práce s JSON. Spíš bych řekl, že vás ani nenapadlo, že byste mohl něco takového potřebovat. Že byste třeba informace z JSON souboru mohl získat jednoduchým dotazem, než abyste něco zjišťoval ručně.
To máte dobré. Pro řešení mých problémů potřebuju získat data z celého JSONu jeho stupidní deserializací. Vybírat kusy pomocí jakýchkoliv dotazů je mi na houby. Prostě řeším úplně jiné problémy, než vy.
Ono to není "XML znovu a hůře".
Bohužel je. Opravdu špatně je na XML jen zmiňované DTD spolu s uživatelskými entitami, a odpůrci XML ani netuší, že něco takového existuje, takže to nemohou kritizovat. Jinak se do JSONu postupně doplňuje vše, co už XML dávno má – pokud je to možné. A když to není možné, jako ty komentáře, začne se vymýšlet nějaký JSON5.
Ono je to "něco jako XML s dost odlišnými kompromisy".
Mohl byste nějaký z těch odlišných kompromisů popsat? Zajímala by mne jediná výhoda JSONu oproti XML. Jaká je výhoda absence komentářů? Jaká je výhoda toho, že se teprve po letech doplňují jazyky pro schémata nebo dotazování, přičemž stále nejsou běžnou součástí nástrojů pro JSON? Jaká je výhoda absence jmenných prostorů?
Že je ukecanější (viz odkaz) a pomaleji se parsuje (viz odkaz)? Že to zrovna ve vašem případě nevadí neznamená, že někdo jiný nemůže řešit diametrálně odlišné problémy, kde to sakra vadí.
Že se to doplňuje až po letech znamená, že to leta nikdo až tak moc nepotřeboval (nebo v případech že jo, použil něco jiného).
A ujalo se právě proto, že ve spoustě případů jsou výhody xml bezcenné a zůstává jen lehký ale všudypřítomný opruz.
Pokaždé, když dělám s JSONem, připadám si, jak kdyby mi chyběly obě ruce. Pro někoho, kdo se narodil už bez rukou, mohou opravdu ruce připadat bezcenné. Ale není to tak. A ten „lehký ale všudypřítomný opruz“ je co přesně? Že vám editor musí doplnit název koncového tagu, a XML se pak mnohem lépe čte?
Spíš jako bez šroubováku. A je spousta programátorů, co už leta nepotkala šroubek, ale zato pravidelně zatloukají hřebíky.
A že se občas ukáže, že byly počáteční analýzy mimo, je bohužel smutná realita vývoje.
Smutná realita v tomto případě je, že jsme tu měli docela dobře fungující XML s ekosystémem, který se dále zlepšoval, a místo toho, aby se odpárala ta jedna nepoužívaná ošklivá vlastnost XML, přišlo se s novým formátem, který měl být údajně jednodušší, ale ve skutečnosti je až tak jednoduchý, až je hloupý.
To "jednoduchý až je hloupý" je ale ta killer featura, kvůli které se ujal. Prostě jsou aplikace, kde cokoliv navíc je fakt zbytečné. Ano, po mnoha letech se pro některé vzácnější případy dolepují další věci. Ale v základu je JSON pořád jednoduchý nástroj vhodný na řešení jednoduchých problémů.
-
Ta cena je rozpuštěná v celkové nešikovnosti a ukecanosti xml.
Jak už bylo napsáno, XML není ukecané.
Napsáno tu bylo spousta věcí. Ale když se podívám na nějaké testy https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml (https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml) nebo https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity (https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity) tak to tak opravdu nevypadá.
Výsledek výkonového srovnání se dá vyložit i tak, že primitivnější nástroje bývají rychlejší, ale umí toho méně.
Stačí se podívat na to, co se porovnává:
<user><id>%d</id><name>%s</name></user>
vs.
{id:%d,name:"%s"}Už z tohoto je vidět, že autor srovnává nesrovnatelné a nerespektuje https://www.json.org/ (https://www.json.org/).
Pokud by to mělo být korektní, tak by to vypadalo takhle:
<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}nebo takhle:
<user id="%d" name="%s"/>
vs.
{"user":{"id":%d,"name":"%s"}}
Jak je vidět, tak v posledním srovnání vychází JSON dokonce o něco delší. V podstatě vyjadřuje i smysl tohoto vlákna: Kdyby se datová struktura XML navrhovala stejně úsporně jako struktura JSON, příznivci JSONu by přišli o argument, že XML je ukecanější.
-
Výsledek výkonového srovnání se dá vyložit i tak, že primitivnější nástroje bývají rychlejší, ale umí toho méně.
A právě o to mi jde. Že jsou situace, kdy primitivnější nástroj bohatě stačí a cokoliv složitějšího je akorát kontraproduktivní.
-
Já to potřebuji tak v polovině případů práce s JSON. Spíš bych řekl, že vás ani nenapadlo, že byste mohl něco takového potřebovat. Že byste třeba informace z JSON souboru mohl získat jednoduchým dotazem, než abyste něco zjišťoval ručně.
To máte dobré. Pro řešení mých problémů potřebuju získat data z celého JSONu jeho stupidní deserializací. Vybírat kusy pomocí jakýchkoliv dotazů je mi na houby. Prostě řeším úplně jiné problémy, než vy.
To je jenom natažení XML nebo JSON do paměti, které je v podstatě stejné. Potom je dobré zkontrolovat, zda je struktura v pořádku, ale povinné to není ani u jednoho. Následuje buď traverzování, anebo vybírání jednotlivých hodnot. U traverzování je postup podobný, ale zahlédl jsem zde, že JSON nezachovává pořadí hodnot v objektu, což může být někdy problém. Při vybírání konkrétní neexistující hodnoty z JSONu dojde k selhání, zatímco XPath vrátí prázdný seznam nebo NULL. Pokud naopak odpovídá více hodnot, XPath vrátí jejich seznam. Zeptat se na rodiče, předchůdce nebo následovníka je v JSONu nepraktické až nemožné. Možná se to někomu jeví jako zbytečné, ale nedovedu si představit, jak bych bez toho zpracovával například ceníky.
-
Výsledek výkonového srovnání se dá vyložit i tak, že primitivnější nástroje bývají rychlejší, ale umí toho méně.
A právě o to mi jde. Že jsou situace, kdy primitivnější nástroj bohatě stačí a cokoliv složitějšího je akorát kontraproduktivní.
Jistě, jen je třeba mít na paměti, že tím vzniká technologický dluh pro budoucí rozvoj.
V PHP je nástroj Composer, který pro ukládání metadat využívá JSON. Při pokusné konverzi do XML dochází ke zkrácení souboru, zlepšení čitelnosti a zjednodušení ruční údržby, která je občas nutná. Autoři Composeru tenkrát zvolili JSON, protože nedocenili budoucí význam tohoto nástroje. Možná v budoucnu změní strukturu na XML, ale bude to bolet. Když to neudělají, bude to bolet také.
-
Ta cena je rozpuštěná v celkové nešikovnosti a ukecanosti xml.
Jak už bylo napsáno, XML není ukecané.
A taky třeba ve velikosti knihoven, které jsou na to xml potřeba.
Nikoli. Pro transformace nebo dotazování jsou jiné knihovny, než pro parsování XML. Složitost XML parserů je způsobená DTD a uživatelskými entitami, které stejně nikdo nepoužívá. Takže by úplně stačilo vydat standard XML 1.2, který tohle vyhodí, kodifikovalo by se tak to, jak se XML reálně používá, a nemuseli se vymýšlet hlouposti jako JSON.
Jak jsem psal, záleží na kontextu. V práci nedělám školní příklady, ale nic ze zmíněného jsem za poslední roky nepotřeboval. I kdyby to bylo úplně zadarmo, tak je mi to k ničemu.
Já to potřebuji tak v polovině případů práce s JSON. Spíš bych řekl, že vás ani nenapadlo, že byste mohl něco takového potřebovat. Že byste třeba informace z JSON souboru mohl získat jednoduchým dotazem, než abyste něco zjišťoval ručně.
Ono to není "XML znovu a hůře".
Bohužel je. Opravdu špatně je na XML jen zmiňované DTD spolu s uživatelskými entitami, a odpůrci XML ani netuší, že něco takového existuje, takže to nemohou kritizovat. Jinak se do JSONu postupně doplňuje vše, co už XML dávno má – pokud je to možné. A když to není možné, jako ty komentáře, začne se vymýšlet nějaký JSON5.
Ono je to "něco jako XML s dost odlišnými kompromisy".
Mohl byste nějaký z těch odlišných kompromisů popsat? Zajímala by mne jediná výhoda JSONu oproti XML. Jaká je výhoda absence komentářů? Jaká je výhoda toho, že se teprve po letech doplňují jazyky pro schémata nebo dotazování, přičemž stále nejsou běžnou součástí nástrojů pro JSON? Jaká je výhoda absence jmenných prostorů?
A ujalo se právě proto, že ve spoustě případů jsou výhody xml bezcenné a zůstává jen lehký ale všudypřítomný opruz.
Pokaždé, když dělám s JSONem, připadám si, jak kdyby mi chyběly obě ruce. Pro někoho, kdo se narodil už bez rukou, mohou opravdu ruce připadat bezcenné. Ale není to tak. A ten „lehký ale všudypřítomný opruz“ je co přesně? Že vám editor musí doplnit název koncového tagu, a XML se pak mnohem lépe čte?
A že se občas ukáže, že byly počáteční analýzy mimo, je bohužel smutná realita vývoje.
Smutná realita v tomto případě je, že jsme tu měli docela dobře fungující XML s ekosystémem, který se dále zlepšoval, a místo toho, aby se odpárala ta jedna nepoužívaná ošklivá vlastnost XML, přišlo se s novým formátem, který měl být údajně jednodušší, ale ve skutečnosti je až tak jednoduchý, až je hloupý. A teď se u tohoto nového formátu s patnáctiletým zpožděním opakuje vynalézání toho, co se vynalezlo u XML. Se stejnými chybami jako u XML a navíc na horším podvozku.
Mimochodem, je zajímavé, že přesně to, co JSON vytýká XML, začali někteří vytýkat JSONu a vytvořili YAML. Nadějné je akorát to, že ty formáty jako JSON a YAML vznikají stále častěji a vzájemně se tlučou, zatímco XML vedle nich stabilně trvá. A má slušné XSD na definici schémat, výborné XSLT 3.0 na transformace, zatím nedoceněné XQuery na dotazování…
+1
-
Napsáno tu bylo spousta věcí. Ale když se podívám na nějaké testy https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml (https://www.infragistics.com/community/blogs/b/torrey-betts/posts/mobile-performance-testing-json-vs-xml) nebo https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity (https://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity) tak to tak opravdu nevypadá.
Napsáno tu bylo spousta věcí, a vy je ignorujete. „Ukecanost“ formátu není užitečná proto, aby se lépe četl strojům, ale aby se lépe četl lidem. Takže ta vaše měření jsou sice hezká, ale měří něco úplně jiného.
Ono se stačí podívat na svg. Velké kusy toho formátu vlastně nejsou xml, ale stringy s vlastním výrazně jednodušším formátem. Přepsat to do xml by i při použití jednoznakových elementů strašně nabobtnalo. Seznamy v JSONu jsou daleko kompaktnější.
Nikdo netvrdí, že SVG je dobře navržený XML formát. Znovu argumentujete tím, že větší XML je špatně, ale otázka zněla, proč je to špatně. Já jsem uváděl důvod, proč „ukecané“ XML je správně. Pokud chci formát, který se bude dobře zpracovávat strojům, nebudu vůbec používat textový formát, ale nějaký binární. JSON je v tomhle horší, protože je špatně čitelný i pro lidi i pro stroje.
Já netvrdím, že XML je vždycky bloat. Ve spoustě případů ta ukecanost nevadí. Ale tvrdit, že ukecané není, je fakt síla.
Jenže tady nikdo netvrdil, že XML není ukecané. Psal jsem, že XML ukecané je, a je to tak záměrně, aby bylo dobře čitelné pro lidi.
Ano, jeden z problémů XML je, že je to moloch.
Co přesně je moloch? Standard, formát, nějaká knihovna?
Ano, kdybychom měli XML bez nevýhod XML, tak bychom JSON možná nepotřebovali.
Které jsou to ty nevýhody? Já jsem psalo jedné vlastnosti, která se prakticky nepoužívá, takže to XML bez nevýhod XML se reálně používá. Navíc pořád nějak nevidím ty výhody JSONu oproti XML. Že nemá komentáře? Že nejsou prakticky dostupné nástroje pro validaci schémat, pro dotazování, pro transformace?
To máte dobré. Pro řešení mých problémů potřebuju získat data z celého JSONu jeho stupidní deserializací. Vybírat kusy pomocí jakýchkoliv dotazů je mi na houby. Prostě řeším úplně jiné problémy, než vy.
Tak to vám gratuluju, že vždy dostáváte jenom perfektně zdokumentované JSONy, u kterých máte 100% jistotu, že té dokumentaci odpovídají. Takže je můžete zpracovávat jenom aplikací a nikdy nemusíte řešit žádné problémy. Mně se dostávají do rukou JSONy, které tak perfektně zdokumentované nejsou, občas je podezření, že někde není něco úplně v pořádku, takže je potřeba ten JSON otevřít ručně a podívat se dovnitř. Až někdy budete muset nějaký JSON otevřít v textovém editoru, pochopíte, o čem píšu.
Že je ukecanější
To je výhoda, nikoli nevýhoda.
pomaleji se parsuje. Že to zrovna ve vašem případě nevadí neznamená, že někdo jiný nemůže řešit diametrálně odlišné problémy, kde to sakra vadí.
Souhlasím, XML se parsuje pomaleji než vhodně zvolený binární formát. Ale pokud budu potřebovat rychlé parsování, nebudu používat JSON. Navíc i to XML může být při parsování rychlejší, protože si můžu pomocí XML schématu určit, že třeba důležité položky mají být na začátku, a zbytek dokumentu můžu klidně ignorovat. JSON musím rozparsovat celý, protože ta důležitá položka klidně může být až úplně na konci.
Že se to doplňuje až po letech znamená, že to leta nikdo až tak moc nepotřeboval (nebo v případech že jo, použil něco jiného).
A nebo nevěděl, že to, co dělá otrocky ručně, se dá dělat i civilizovaně.
Spíš jako bez šroubováku. A je spousta programátorů, co už leta nepotkala šroubek, ale zato pravidelně zatloukají hřebíky.
Ne, je to jako bez rukou. Ano, někteří lidé, kteří se bez rukou narodili, zvládnou i nohama nebo ústy neuvěřitelné věci, ale drtivá většina lidí lépe a rychleji píše, jí, obléká se a jinak pracuje rukama než nohama. A to, že jste nikdy nepotřeboval otevřít JSON v textovém editoru a něco tam najít nebo třeba spočítat počet položek, vám nevěřím.
To "jednoduchý až je hloupý" je ale ta killer featura, kvůli které se ujal.
Nikoli, ujal se proto, že se (zpočátku natvrdo přes eval()) používal na webu, a web zažil obrovský rozmach. A ruku v ruce to šlo s tím, že lidé od webu byli zvyklí, že nemají pořádné nástroje ani specifikace a musí spoustu věcí řešit hrubou lidskou silou, takže jim na JSONu nepřišlo nic zvláštního.
Prostě jsou aplikace, kde cokoliv navíc je fakt zbytečné.
Vy se pořád tváříte, jako by to „něco navíc“ bylo v XML povinné a nějak vám to překáželo. Když nechcete používat schémata, transformace nebo dotazování, používat to nemusíte, a neplatíte za to žádné náklady. Ale máte tu možnost.
A pořád jste nenapsal, které jsou ty aplikace, kde by byl problém, kdyby JSON měl třeba komentáře.
Ale v základu je JSON pořád jednoduchý nástroj vhodný na řešení jednoduchých problémů.
Ty jednoduché problémy, které řeší JSON, řeší XML lépe. Jediná věc, ve které je JSON skutečně lepší, než XML, je ta, že parser z JSONu do JavaScriptových objektů je součástí webových prohlížečů, ale parser z XML do JavaScript objektů ve webových prohlížečích není. Bohužel tohle je ta klíčová vlastnost, která rozhodla v případě webu. Ale je vidět, že jinde JSON neuspěl – sice se z webu šířil dál, ale lidé s ním nejsou spokojení. Proto vznikl třeba YAML.
-
Jenže tady nikdo netvrdil, že XML není ukecané. Psal jsem, že XML ukecané je, a je to tak záměrně, aby bylo dobře čitelné pro lidi.
Ehm... Kdyby to aspoň napsal někdo jiný...
Jak už bylo napsáno, XML není ukecané.
Až se rozhodnete, jestli xml není ukecané, nebo je dobře že je ukecané, tak možná bude mít smysl o něčem diskutovat.
-
Výsledek výkonového srovnání se dá vyložit i tak, že primitivnější nástroje bývají rychlejší, ale umí toho méně.
A právě o to mi jde. Že jsou situace, kdy primitivnější nástroj bohatě stačí a cokoliv složitějšího je akorát kontraproduktivní.
Jistě, jen je třeba mít na paměti, že tím vzniká technologický dluh pro budoucí rozvoj.
V PHP je nástroj Composer, který pro ukládání metadat využívá JSON. Při pokusné konverzi do XML dochází ke zkrácení souboru, zlepšení čitelnosti a zjednodušení ruční údržby, která je občas nutná. Autoři Composeru tenkrát zvolili JSON, protože nedocenili budoucí význam tohoto nástroje. Možná v budoucnu změní strukturu na XML, ale bude to bolet. Když to neudělají, bude to bolet také.
A tady zrovna silně nesouhlasím. Technologický dluh je to v případě, že vím že budu v budoucnu chtít rozšiřovat nějakým konkrétním směrem. Pokud to nevím, pak je to jenom rozhodování na základě neúplných informací. A těch možných směrů rozšíření je obvykle k dispozici víc.
Souhlasím, že pokud vím že budu v budoucnosti dělat něco kde se víc hodí XML, tak je blbost použít JSON. Ale dává to smysl, pokud momentálně potřebuju něco na co JSON bohatě stačí a vůbec netuším, kam ten vývoj bude v budoucnosti směřovat.
-
Stačí se podívat na to, co se porovnává:
<user><id>%d</id><name>%s</name></user>
vs.
{id:%d,name:"%s"}Už z tohoto je vidět, že autor srovnává nesrovnatelné a nerespektuje https://www.json.org/ (https://www.json.org/).
Pokud by to mělo být korektní, tak by to vypadalo takhle:
<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}nebo takhle:
<user id="%d" name="%s"/>
vs.
{"user":{"id":%d,"name":"%s"}}
Jak je vidět, tak v posledním srovnání vychází JSON dokonce o něco delší. V podstatě vyjadřuje i smysl tohoto vlákna: Kdyby se datová struktura XML navrhovala stejně úsporně jako struktura JSON, příznivci JSONu by přišli o argument, že XML je ukecanější.
A ještě k tomuhle. On v tom srovnání vysvětluje, proč použil tu ukecanější variantu. Je to proto, že XML dovoluje právě víc zápisů a v dost případech je použita právě ta delší. Vždyť i tohle vlákno začalo tím, jestli použít tu delší nebo kratší verzi. Takže dává smysl se ptát, jaká je cena za tuhle flexibilitu (obzvlášť pokud zůstane nevyužitá).
-
Kdyby se datová struktura XML navrhovala stejně úsporně jako struktura JSON, příznivci JSONu by přišli o argument, že XML je ukecanější.
A ještě k tomuhle. On v tom srovnání vysvětluje, proč použil tu ukecanější variantu. Je to proto, že XML dovoluje právě víc zápisů a v dost případech je použita právě ta delší. Vždyť i tohle vlákno začalo tím, jestli použít tu delší nebo kratší verzi. Takže dává smysl se ptát, jaká je cena za tuhle flexibilitu (obzvlášť pokud zůstane nevyužitá).
Vlákno začalo dotazem, zda ostatní využívají atributy v XML nebo dávají přednost delší verzi. Ptal jsem se na názor, je to tedy spíš anketa než dotaz na doporučení. V každém případě jsem z toho zjistil dost zajímavých věcí.
JSON také dovoluje víc zápisů a zvolil ten kratší. Takové srovnání je prostě nefér, protože kdyby tam chtěl přidat další "name", tak se mu ten formát rozsype, zatímco delší XML to normálně přijme a zpracuje. Proto jsem uvedl v obou případech delší a kratší zápisy, aby se srovnávalo srovnatelné.
-
Jenže tady nikdo netvrdil, že XML není ukecané. Psal jsem, že XML ukecané je, a je to tak záměrně, aby bylo dobře čitelné pro lidi.
Ehm... Kdyby to aspoň napsal někdo jiný...
Jak už bylo napsáno, XML není ukecané.
Až se rozhodnete, jestli xml není ukecané, nebo je dobře že je ukecané, tak možná bude mít smysl o něčem diskutovat.
Kdybyste řešil smysl textu, a ne jaká konkrétní slovíčka jsou použitá v které větě, bylo by vám to jasné.
XML je „ukecané“ v tom smyslu, že jsou tam věci, které by se daly odstranit a pro stroj by to stále bylo čitelné. Ta „ukecanost“ je ale záměrná, aby se s tím lépe pracovalo lidem. Není to „ukecanost“ v tom smyslu, že by to překáželo lidem při čtení, že by si říkali „bla bla bla, to už víme, dál“. Je to něco jako samoopravné kódy, ale pro lidi. Už to chápete?
-
A ještě k tomuhle. On v tom srovnání vysvětluje, proč použil tu ukecanější variantu. Je to proto, že XML dovoluje právě víc zápisů a v dost případech je použita právě ta delší. Vždyť i tohle vlákno začalo tím, jestli použít tu delší nebo kratší verzi. Takže dává smysl se ptát, jaká je cena za tuhle flexibilitu (obzvlášť pokud zůstane nevyužitá).
Ehm... Kdyby to aspoň napsal někdo jiný...
Použil tu ukecanější variantu, takže tu flexibilitu, že může použít i delší zápis, využil.
-
Jenže to je šetření na špatném místě. Třeba transformační a dotazovací jazyky mne nic nestojí, jsou vedle původního standardu a když nechci, vůbec je používat nemusím. Jenže i když chci serializovat nebo deserializovat jednoduchou datovou strukturu, jakmile opustím školní příklady, zjistím, že bych strukturu serializovanou jedním způsobem potřeboval deserializovat jinde, kde se očekává mírně odlišný formát, nebo potřebuju někde jenom ručně ověřit, kolik tam je vlastně položek atd. A najednou se mi hodí, že ty transformační a dotazovací jazyky mám po ruce a můžu je hned použít.
Ona ostatně není náhoda, že i pro JSON dotazovací jazyky existují, a myslím, že je snaha vytvořit i nějaký transformační jazyk. Takže všechno, co je na XML údajně zbytečné, se k JSONu postupně doplňuje. Akorát je trochu smutné, že JSON je vlastně takové „XML znovu a hůře“.
Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).
-
Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).
jenomže xslt, xpath, xquery nejsou “nezávislé nástroje” ale provázané standardy.
-
Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).
Bavíme se o výhodách a nevýhodách atributů v XML. Tedy něčeho, co JSON nezná. Dovedu si představit, že by se dal k JSONu vytvořit nějaký omezený JPath nebo JQuery, ale JSLT? Ne, na to ten formát nemá.
-
Měl jsem za to, že se bavíme o přednostech a nedostatcích formátů, ne o nezávislých nástrojích k nim vytvořených (které si koneckonců můžete vyrobit i sám).
Pokud se budeme bavit pouze o samotném formátu a budeme ignorovat infrastrukturu, která kolem formátu existuje, bude vždy nejlepší nějaký vlastní proprietární formát vytvořený přesně na míru danému případu. Napíšete si k němu superrychlý parser, vlastní serializer a vše, co budete potřebovat.
V praxi to tak ale asi dělat nebudete, protože by pro vás bylo příliš nákladné vytvářet si i jen minimální infrastrukturu kolem toho vašeho formátu. Takže reálně nemá smysl porovnávat jen samotný formát, ale formát s celou tou infrastrukturou okolo. Proto se také v prohlížečích rozšířil JSON, protože v nich má lepší podporu než XML – a zároveň je tohle shodou okolností jediný důvod, proč se vůbec JSON rozšířil.
-
Pokud by to mělo být korektní, tak by to vypadalo takhle:
<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}...
Ale takhle to nikdo používat nebude, JSON vícevýznamové položky nevede, k ničemu to nepotřebuje.
Ale jestli takhle XML ukládá seznamy, tak tím bych si netroufnul se camrat - 1. nejde bez průchodu celé podstruktury poznat, jde-li o seznam nebo ne, 2. jednotlivé seznamy se mohou prolínat, 3. každý prvek seznamu prodlužuje zápis opakováním tagů názvu seznamu. 4. Zdvojuje se význam tagu na název seznamu obsahujícího položku a zároveň název samostatné položky. To má k eleganci a přehlednosti dost daleko.
-
Pokud by to mělo být korektní, tak by to vypadalo takhle:
<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}...
Ale takhle to nikdo používat nebude, JSON vícevýznamové položky nevede, k ničemu to nepotřebuje.
Ale jestli takhle XML ukládá seznamy, tak tím bych si netroufnul se camrat - 1. nejde bez průchodu celé podstruktury poznat, jde-li o seznam nebo ne, 2. jednotlivé seznamy se mohou prolínat, 3. každý prvek seznamu prodlužuje zápis opakováním tagů názvu seznamu. 4. Zdvojuje se význam tagu na název seznamu obsahujícího položku a zároveň název samostatné položky. To má k eleganci a přehlednosti dost daleko.
JSON i XML používají jen seznamy a slovníky. Co je myšleno tím prolínáním? Značky názvů seznamů jsou nepovinné. Dávají se tam kvůli lepší čitelnosti člověkem.
Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se. Možná i proto, že nemá ukončovací značku.
-
Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.
V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.
-
Když navrhuji vlastní formát XML, tak je přede mnou rozhodnutí, zda pro danou hodnotu použiji element či atribut.
...
Jak navrhujete vlastní formáty XML? Proč dáváte přednost první variantě nebo proč druhé?
Já preferuji atributy. Snáze se mi s tím pracuje. Elementy použiji jen když chci ukládat text, který může obsahovat whitespace. Obzvláště když se tam může objevit konec řádku, protože s tím ani CTYPE nepomůže. Pro tyhle situace je pro mne výhodnější tam dát element a vyhnout se případným zmatkům s normalizací.
http://www.xml.com/axml/target.html#AVNormalize
-
Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.
V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.
Měl jsem na mysli takový zápis, který by snad měl být kompatibilní ve všech Lispech a zároveň řeší problém atributů, které v něm nemusí být skalární:
(user :id 42 :name "Název")
vs.
<user id="42" name="Název"/>
vs.
{"user":{"id":42,"name":"Název"}}
-
Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.
V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.
Měl jsem na mysli takový zápis, který by snad měl být kompatibilní ve všech Lispech a zároveň řeší problém atributů, které v něm nemusí být skalární:
(user :id 42 :name "Název")
vs.
<user id="42" name="Název"/>
vs.
{"user":{"id":42,"name":"Název"}}
to by asi šlo, ale když JSON doplním o konstruktory, dostanu něco podobného.
user("id",42,"name","Název")
-
Jako značkovací jazyk by se mi líbil i Lisp, protože je ještě stručnější než JSON, ale neujal se.
V kterém Lispu? Co konkrétně je stručnější než v JSONu? AFAIK neexistuje zápis mapy kompatibilní napříč Lispy.
Měl jsem na mysli takový zápis, který by snad měl být kompatibilní ve všech Lispech a zároveň řeší problém atributů, které v něm nemusí být skalární:
(user :id 42 :name "Název")
vs.
<user id="42" name="Název"/>
vs.
{"user":{"id":42,"name":"Název"}}
to by asi šlo, ale když JSON doplním o konstruktory, dostanu něco podobného.
user("id",42,"name","Název")
nebo asi lepe
user({id:42,name:"Název"})
je to stejně dlouhé
-
user({id:42,name:"Název"})
je to stejně dlouhé
Už tady bylo jasně řečeno, ža nezáleží na délce, ale na tom, co s tím umíš :)
-
user({id:42,name:"Název"})
je to stejně dlouhé
Už tady bylo jasně řečeno, ža nezáleží na délce, ale na tom, co s tím umíš :)
mohu to vyevalovat stejně jako ten Lisp. Nebo pro tu Lispovou notaci existují nějaké nástroje?
-
user({id:42,name:"Název"})
je to stejně dlouhé
Už tady bylo jasně řečeno, ža nezáleží na délce, ale na tom, co s tím umíš :)
mohu to vyevalovat stejně jako ten Lisp. Nebo pro tu Lispovou notaci existují nějaké nástroje?
Záleží na tom, jak to v tom Lispu načteš. Když data čteš přes (read), tak se parsují do datového stromu, ale nevyhodnocují. Můžeš s nimi naložit jak chceš, třeba i ten eval, který nechceš.
Zkratka REPL znamená Read Evaluate Print Loop, což je smyčka, která se spustí na konzoli při načtení Lispu. Používá se pro načtení aplikace. Při načítání dat ze souboru tuto smyčku nepoužiješ, jenom čteš. V aplikaci si pak uděláš vlastní validaci a vyhodnocení dle potřeby. Funkce car a cdr jsou významným spojencem programátora.