Vlákno názorů k článku
GIMP chystá nový formát na bázi XML, náhradu za XCF od Jan - Já jsem si myslel, že i XML již...

Já jsem si myslel, že i XML již došel před několika lety dech, takže mě překvapuje, že někdo ještě přechází na zastaralý formát, který se i pomalu parsuje a nepřejde rovnou na json. A ten json by se možná ani nemusel komprimovat, pokud by se vypustily mezery.

Řekl bych, že důvodů může být víc. Gtk a kód Gimpu už teď používají různé součásti v xml, tak proč v tom dělat zmatek přidáním nového jsonu. Druhá věc je, že xml v zipu je imho dnes takový víceméně standard, vezměte si třeba docx, odf, nebo třeba xml z inkscapu, všechno xml.
A on tam bude asi i nějaký technický důvod, co v xml udělat jde a v json ne, ale ten teď neumím zodpovědět.

Ono je to jednoduché: element v XML může mít více atributů, JSON je v podstatě jen klíč:hodnota. Ne, že by to nebylo (celkem snadno) řešitelné, ale tak nějak se s tím pak blbě dělá.

Osobně jsem nepochopil, v čem je výhoda těch XML atributů, a čím se to liší od dalšího vnořenýho elementu.
Je tam nějaká významová nebo funkční nuance?

<faktura customerId=11>
<položky>...</po­ložky>
<faktura>

vs
<faktura>
<customerId>11</cus­tomerId>
<položky>...</po­ložky>
<faktura>


Ne, že by to nebylo (celkem snadno) řešitelné, ale tak nějak se s tím pak blbě dělá.
Proč? Je tam nějakej logickej problém? Nebo je to kvůli dostupným nástrojům?

Přesně ten problém, který jste popsal: na první pohled nerozeznáte vnořený element od atributu elementu (a je potřeba to vědět).
Většinou to je opravdu jedno a nemá to vliv ani na funkci rostlináře.

Atribut je max 1 a je to kontrola na urovni jazyka. Je to v principe vzdy jedinecna vlastnost viditelna pre kazdeho. Nejde to zmenit v zmysle "teraz sa nieco pridalo, pridam to tam viackrat".

Potom samozrejme v scheme je mozne to obmedzit aj v scheme, ale na pochopenie toho treba citat schemu.

Je to proto, že XML původně vznikl jako formát pro značkování textu. A v textu je podstatně lepší značkovat takto:

Toto je opravdu <style bold="true" emphasis="true" color="red" author="Big Boss">důležité</style> upozornění! 

Než takto:

Toto je opravdu
<style>
  <bold>true</bold>
  <emphasis>true</>
  <color>red</color>
  <author>Big Boss</author>
důležité
</style>
upozornění! 

Namespaces

A ja este pridam svoj uhol pohladu. XML Schema je lepsia ako JSON schema.

Pomaly sa parsuje, ale ma "zadarmo" schemy, ktore hned vygeneruju aj struktury v programovacom jazyku. Ma aj standardizovane vyhladavanie pre tych, ktori to nechcu cele parsovat (XPath).

JSON ma tiez schemy, ale tam sa nepresadili, jq je jeden nastroj a nie siroko implementovany standard.

Aj ked je pravda, ze sa od XML ustupuje, stale je za mna viac pouzitelny.

XML je pořád výrazně lepší než JSON. JSON má oproti XML jedinou výhodu – když ho chcete ve velkém editovat ručně (ale nechcete tam dávat poznámky, což je u ruční editace časté).
Nekomprimovaný JSON s obrázkem by pořád byl obrovský.
XML má pro tohle použití jednu obrovskou výhodu – je od začátku navrženo jako rozšiřitelné. Vznikne nový plugin do Gimpu? Vytvoří si nový namespace a může si do XML ukládat svá data kam potřebuje. Tohle s JSONem nejde, tam si musí rozšiřitelnost každý nějak vymyslet po svém. Navíc XML má lepší možnosti definice schématu, můžete třeba předepsat, že důležité informace potřebné pro rychlé zobrazení musí být na začátku.
Navíc v grafickém editoru asi bude docela důležité ukládání čísel, přičemž JSON vůbec neřeší, že jsou různé reprezentace čísel v aplikacích. Je číslo v JSONu 32bitové celé číslo? Se znaménkem nebo bez? Nebo je 64bitové? Nebo je 32bitové nebo 64bitové v plovoucí řádové čárce? Nebo něco jiného?

XML zrovna formát čísel taky neřeší. Pokud si to nějakým atributem neuděláte po svém.

Jenže XML vůbec nepředstírá, že přenáší čísla. XML přenáší jenom text, jako číslo ho můžete interpretovat. A při té interpretaci většinu lidí napadne ptát se, co je to za číslo. A obvykle to najdou ve schématu.

JSON se tváří, že přenáší číslo, schéma se ve spoustě případů neřeší, vždyť typy jsou přece přímo v JSONu. A pak se částka uloží do JSONu jako číslo a interpretuje se jako float nebo double…

jj, nejlepsi sou henty "moderni" formaty., ktery neumej ani rict, jestlit am ten prvek vubec muze byt, natoz jaky ma mit typ ... a pak se na to vymejslej vsemozny vzajemne zcela nekompatabilmi vohejbaky narovnavaku ...

Jestli je nějaký formát který umí nahradit XML, je to KDL, rozhodně ne JSON.

KDL ale taky není všeobecně rozšiřitelné. Tam je hlavní výhodou čitelnost.

XML jako formát pro komunikaci mezi stroji by spíš nahradil třeba CBOR.

Ten umí reprezentovat konkrétní datové typy a je rozšiřitelný pomocí tag záznamů. A navíc je standardizovaný.

CBOR je binarni. To ma plusy i minusy. Tedy to neni rozhodne nahrada za json/xml. I kdyz json i xml se pouzivaji kde by se CBOR hodil vice. Ty "stringy" na presun dat se rozsirili, protoze autorum, a tem co to po nich udrzuji, umoznuji kouknout co to vlastne posilaji/prijimaji. Taky ten string ma (bohuzel) nejvetsi vyjadrovaci schopnost a halvne rozsiritelnost.

Ano, je binární, ale nese si svoji strukturu (narozdíl od ASN.1 nebo protobuf) a umí i sémantické tagy (narozdíl od MessagePacku). Je standardizovaný a rozšiřitelný včetně správy pod IANA - https://www.iana.org/assignments/cbor-tags). Má podporu pro schémata v CDDL.

> I kdyz json i xml se pouzivaji kde by se CBOR hodil vice.

No právě.

> Ty "stringy" na presun dat se rozsirili, protoze autorum, a tem co to po nich udrzuji, umoznuji kouknout co to vlastne posilaji/prijimaji.

Pro debugging se dá jednoduše převést do textové formy (jedna je standardizovaná [1], ale jednodušší věci jdou i přímo do jsonu).

[1] Diagnostic notation - https://www.rfc-editor.org/rfc/rfc8949.html#name-diagnostic-notation

Ale pochopitelně vím jak je to se setrvačností a komunitním vývojem. Takže si nedělám iluze o masivním rozšíření.

Ha, KDL vypada skvele. Konecne neco, do ceho clovek dokaze zapsat jednoduchou matici, aniz by se zblaznil ze zavorkovani nebo <> a porad to videl jako matici.
A ma to vic implementaci nez ten muj osobni tupy format co pouzivam pro sve potreby.

O kdl sem doted neslysel, a koukal jsem do toho dosti znechucene jakoze "proc dalsi jsonoxml". Pak sem si taky vsiml te matice. Ta vypada skvele. lLe stejen. `\` je jen zapisovy cukr ala bash(?), nebo to opravdu dela neco vice a dostanu array[][]?

nevim, budu muset podrobne prozkoumat.
Ja mam problem ze potrebuju ukladat ruzna data, ktera si pak potrebuji prohlizet lidi, a pripadne je potrebuji lehce upravovat, nebo z toho neco zkopirovat, nebo nahradit. A dost casto se mi objevuji i matice (ne pouhe vektory), kde clovek potrebuje zmenit jedno dve cisla, pripadne z jinych mereni a formatu prepsat matici 3x4 a pod. Vetsina formatu s maticema nepocita a testy na uzivatelich dopadly spatne, json je nevhodny, yaml taky, xml katastrofa, lidi v tom delaji chyby a pak neco nefunguje. Muzu dodelavat ruzna GUI aby to tam lidi nastrkali spravne, ale to je pruda. Takze pouzivam nejaky upraveny vlastni neco jako ini, ale je to domaci reseni a rad bych neco obecne prijimaneho.

Je to jen "zápis pokračuje na další řádce", nic víc :(

Komprimace u XML me prijde jako nevyhoda.

Dala by se pochopit, kdyby to bylo z duvodu "kontejneru", ze k xml pridate bloby a obrazky.

Ale neskutecne to stezuje vyhledavani v souborech.. pro stare .doc mi staci hledat (napr. pres total commander, ale lze to aplikovat i pro strings, grep) textovy retezec v unicode formatu.. pro docx musite mit predem naindexovany vsechno - anebo porad rozbalovat cely kontejner :/

Neparsuje sa pomaly, stale je to format vhodnejsi na ukladanie dat ako JSON.
JSON sa presadil v API a to preto, ze javascript v prehlidacoch nic ine nevie.

XML ma schemu, ktora funguje, namespaces, lahsie sa edituje aj cita (pri hlbokom zanoreni) a po kompresii je rovnako velky ako JSON.

Tak zrovna na ukládání dat vhodnější rozhodně není. Vhodnější je pro interoperabilitu. Parsovat XML je náročnější ale nemyslím, že by to tady byl problém. A JSON se rozhodně neprosadil proto, že "javascript v prehlidacoch nic ine nevie" ale proto, že to bylo praktické. S touhle logikou by se XML neprosadil víceméně nikde -- a přece se prosadil. Protože obojí má své výhody i nevýhody.

"ale proto, že to bylo praktické."

Nikoli, prosadil se proto, ze to pisou patlalove, kteri o tom co pisou vubec nic nevedi a XML je prece "silene slozite". A jakmile to pak ma nekdo nekdy udrzovat, je jednodussi to napsat cely znova. Protoze kdyz do jsonu neco pridam, tak tim narozdil od xml rozbiju uplne vsechno.

A to je presne ten duvod proc je naopak XML ten vhodny format, protoze kdyz rekneme napisu prohlizec, a nekdo si vymysli ze do formatu prida nejakou novou vlastnost, tak ten prohlizec bude dal fungovat, jen nebude chapat tu novou vlastnost.

Viz treba epub. Chces indexovat nazvy a autory? Neni nic snazsiho ...

Parsovat XML je náročnější
Než JSON? V čem?

A JSON se rozhodně neprosadil proto, že "javascript v prehlidacoch nic ine nevie" ale proto, že to bylo praktické.
Ale JSON se prosadil proto, že v prohlížečích se na to zavolal eval() a data byla rovnou v paměti v nativních strukturách JavaScriptu. Zpočátku to byl vyloženě kód, který vytvořil proměnnou. Pak se řeklo, že se tomu dají nějaká omezení, aby se tam nemohl spouštět úplně libovolný kód, a pojmenování se ponechá na tom, kdo data načítá – ale pořád to šlo řešit pomocí eval(). Tak vznikl JSON. Nakonec se přišlo na to, že parsovat data pomocí eval() není zrovna bezpečné a do prohlížečů se doplnily funkce pro jeho parsování.

Ve skutečnosti uměly s XML prohlížeče pracovat daleko dřív, než měly nativní podporu JSONu. Ale použití JSONu bylo v prohlížeči daleko jednodušší.

> Ve skutečnosti uměly s XML prohlížeče pracovat daleko dřív, než měly nativní podporu JSONu.

Ano pre to sa vola AJAX AJAX.No je tam ale - prehliadace to nikdy neimplementovali dobre, napriklad nikdy nevedeli pouzivat namespaces.

> "Parsovat XML je náročnější"
> Než JSON? V čem?

Parsovat XML správně je o mnoho náročnější. Namespaces, CDATA atd. Napsat plně funkční a validní XML parser vlastně ani nejde, protože existují šedá místa (třeba XML v CDATA bloku v XML), která se nedají vždy interpretovat jednoznačně.

JSON je primitivní formát se všemi výhodami a nevýhodami z toho plynoucími.