Názory k článku
GIMP chystá nový formát na bázi XML, náhradu za XCF

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.

To bude zase pomalé. Nechápu, proč si nevyberou binární formát, který jde efektivně parsovat, ideálně pomocí SIMD instrukcí. Nebo formát, co se nemusí parsovat vůbec a jeho načtení odpovídá přímo strukturám v paměti.

Nechápu, proč si nevyberou binární formát, který jde efektivně parsovat, ideálně pomocí SIMD instrukcí.
Protože parsováním se stráví zlomek času a u formátu jsou podstatně důležitější věci, než rychlost parsování.

Nebo formát, co se nemusí parsovat vůbec a jeho načtení odpovídá přímo strukturám v paměti.
Tím už si všichni prošli před desítkami let a zjistili, že je to peklo.

> u formátu jsou podstatně důležitější věci, než rychlost parsování.

A co třeba?

Třeba možnosti zpětně kompatibilního rozšíření formátu (nové funkce se ignorují, ale zbytek je zpracovatelný).

Ale to přeci jde i v binárním formátu, co se rychle parsuje. Důkazem jsou již existující formáty obrázků.

A jde to třeba i u C struktur, které můžu rozšiřovat a starý kód, který očekával struktury s méně fieldy stále funguje - jen prostě nečte ty další fieldy.

Struktury v paměti narazí hned při přechodu mezi little- vs. big-endian, jiným ABI pro padding nebo při jiné délce intu mezi platformami. Navíc se typicky nedají zpracovat jako stream a musí se načíst celé.

Binární strukturovaný formát by byl fajn. Ale na XML existuje spousta nástrojů a jestli GIMP už XML používá, tak jde o "malou" změnu oproti ostatním možnostem.

A kolik platforem je dnes big-endian? Číselné typy pak můžete zvolit s konkrétní velikostí a padding i alignment ovlivnit.

Nechápu, proč si nevyberou binární formát,
Jen to ne, pak bude chtít uživatel něco upravit mimo gimp a bude muset mít specializované nástroje místo "hloupého" nahrazení textu. Nehledě na dopřednou kompatibilitu (v textu je jednodušší ignorovat neznámé fieldy než ve špatně navržené binární struktuře). Navíc je třeba o dost větší pravděpodobnost že takové LLM bude daný formát chápat z dokumentace aniž by se musel dělat nějaký specializovaný MCP server který ji to bude překládát. Za mě binární formáty jsou hezké, ale tam kde je třeba opravdu optimalizovat. Ale v době kdy téměř všichni uživatelé doma mají kompy jejichž výkon ztěží dokážou využít mě to přijde jako optimalizace jen aby se mohlo říct že to je super-optimální bez nějakých extrémních přínosů pro koncáky (ještě navíc při načítání a ukládání souboru -- kolikrát to uživatel dělá?).

19. 8. 2026, 13:11 editováno autorem komentáře

A kolikrát to uživatel edituje mimo GIMP? Očekávám, že méně často než ukládá a načítá v GIMPu.

Uzivatel malo, ale softwaru co nyni umi nacist XCF je celkem dost. V pripadne binarnich dat se takovy format hur siri, protoze se hur implementuje do jineho softwaru (narozdil od XML parseru).

Hodně záleží jaký binární formát zvolíte. On to nemusí zrovna být ručně psaný a s ničím nepodobný bordel. Máme i moderní strukturované binární formáty.

Já jsem takhle opravoval bakalářskou práci, kde se OpenOffice rozhodl, že vše od stránky 12 dál bude v poznámce pod čarou. Naštěstí to bylo právě XML v ZIPu, takže jsem přesunul konec jednoho tagu na správné místo. Kdyby to byl binární formát, třeba DOC, nezbylo by mi nic jiného, než vyexportovat text jako čistý text a naformátovat to celé znovu, včetně vkládání obrázků, grafů, tabulek, citací, poznámek pod čarou apod. Protože v programu s tím nešlo hnout, když jsem kus vyjmul do schránky a chtěl sem ho vložit zpátky do hlavního toku dokumentu, jenom z toho vyrobil další poznámku pod čarou.

Je to extrémní příklad, ale prostě jsou situace, kdy jste rád, že na ten soubor můžete sahat běžnými a spolehlivými programy, protože nativní aplikace něco neumí, nebo něco pokazila.

Grafici načítají a ukládají velké soubory s mnoha a mnoha vrstvami poměrně dost často.

A datový formát GIMPu bude stejně binární. Bude to pravděpodobně archiv komprimovaných XML metadat a vektorů + binárních bitmap.