Vlákno názorů k článku Plnotučné tabulky v LaTeXu s balíkem tabularray od K> - K tomu zda stale frci TeX - a...

Pro dokumentaci struktury XML existují standardy, umí je používat třeba editory, které na základě toho mohou napovídat. Takže třeba do editoru nemusíte programovat podporu pro 20 DSL pro různé balíky TeXu, ale stačí jedna obecná pro XSD.

To, že nemusím řešit, jestli se parametry předávají pozičně nebo jménem; jestli je za jménem rovná se, dvojtečka nebo něco jiného; jestli se víc parametrů odděluje mezerou, čárkou nebo středníkem; jestli se texty píšou do dvojitých uvozovek, jednoduchých uvozovek, složených závorek nebo nějak jinak – to všechno dost usnadňuje práci. Zejména když nepoužíváte jenom jeden formát s jedním rozšířením, ale těch formátů a rozšíření používáte dohromady desítky.

".. existují standardy ..."

Jo, několik konkurenčních. A spojuje je to, že jsou čitelné jen pro někoho, kdo se na xml specializuje.

Programátor, který se specializuje na něco jiného, si buď použití xml rozmyslí, nebo si tu validaci napíše ručně. Jak ta podpora pro XSD, tak popis nějakého formátu v XSD jsou extrémně složité v porovnání s tím naprogramovat podporu pro nějaký formát přímo.

Ten druhý odstavec usnadňuje hlavně strojové zpracování. Jako člověku mi standardizovaný způsob předávání parametrů moc nepomůže. Stejně se musím kouknout do manuálu, jaké parametry tam vůbec jsou a co dělají. A to jen v případě, že daný xml formát jen nestrčí nějak strukturovaná data dovnitř xml atributů (jako to dělá třeba SVG).

Rodina XML věcí vyžaduje dost drsné počáteční investice. Nepříjemně často se to vůbec nevyplatí.

Zrovna TeX je v tom nevinně, protože vzniknul dávno před XML. Problém je v nových jazycích, kdy aby se člověk nemusel učit „složité“ XML, musí se učit GitHub Markdown, StackOverflow Markdown, Slack Markdown, JSON, JSON5, YAML…

Ve skutečnosti validaci nebo podporu toho proprietárního formátu nenapíše nikdo. Nebo si myslíte, že teď pro tabularray bude vznikat speciální podpora pro všechny textové editory, které se používají?

Standardizovaný formát parametrů vám samozřejmě pomůže, protože začnete psát col, a editor už vám doplní, jestli je to colspan nebo col-span. V případě proprietárního formátu musíte jít do dokumentace a začít zjišťovat, jak se to vůbec zapisuje.

No ano. Místo složitého xml se rychleji naučím jednodušší Markdown. Všechny ty tři markdowny jsou rozšíření společného základu, který v drtivé většině případů stejně stačí. Přechod mezi těmi variacemi je poměrně triviální.

Je to specializovaný nástroj pro omezenější spektrum problémů. Snaží se dělat jednu věc a díky tomu ji může dělat podstatně líp než to xmlko, protože nemusí platit cenu za obecnost.

Problém je, že nakonec skoro vždycky potřebujete něco komplexnější, a pak už jenom navěky platíte cenu za to, že se pomocí něčeho příliš jednoduchého snažíte řešit složitější problém. Proto existuje tolik variant Markdownu a jakmile chcete něco trošinku složitějšího, místo jednoduchého psaní musíte začít řešit, která varianta Markdownu se používá a kde má dokumentaci. Nebo se podívejte na jazyk Wikipedie – o co snazší by bylo psát zdrojové kódy (a o co dřív by existoval WYSIWYG editor), kdyby to bylo XML. Zatímco takhle to používají jenom lidé, kteří se na Wikipedii specializují – a ostatní sem tam doplní nějaký text, ale málokdo se pustí do používání šablon apod., protože se mu nevyplatí studovat to kvůli jedné editaci.

V tom xml ekosystému ale taky není jen jedna alternativa Markdownu, že?

Problém je IMO ten, že dopředu nevíte, v čem to bude muset být komplexnější. Pokud začnete s něčím jednodušším, budete to muset ohýbat. Pokud vyberete něco složitějšího, budete celou dobu platit za potenciálně nevyužitou složitost. A možná to budete muset ohýbat taky, protože nic není připravené na jakoukoliv eventualitu.

To xml je zrovna ukázkový příklad. Třeba typů pro atributy je dost omezená nabídka, takže se tahle nedostatečná podpora strukturovaných typů hákuje poměrně často (třeba to SVG).

S čím souhlasím je, že kdyby jazyk Wikipedie byl postavený nad XML, tak by dřív existoval editor. Ono se totiž xml bez podpory editoru píše dost blbě. V porovnání třeba s Texem nebo tím Markdownem je tam hromada mechanického datlování.

V XML ekosystému nemusí nikdo vymýšlet svojí odlišnou variantu Markdownu, jenom přidá k základní variantě své další elementy či atributy v novém jmenném prostoru. A když už vzniknou varianty řešící totéž, což je v pořádku (jako vznikly různé balíky řešící tabulky pro LaTeX), dá se mezi nimi jednoduše provádět transformace v XSLT.

Problém je IMO ten, že dopředu nevíte, v čem to bude muset být komplexnější.
To právě u rozumně navrženého jazyka, který počítá s rozšiřitelností, problém není.

Třeba typů pro atributy je dost omezená nabídka
Ta omezená nabídka zahrnuje všechny typy používané v běžných programovacích jazycích. A je podstatně širší, než třeba v JSONu nebo YAMLu. Na rozdíl od JSONu jsou ty typy také dobře definované.

třeba to SVG
V SVG je to udělané špatně. Autoři se úplně zbytečně lekli toho, že by to udělali tak, jak to v XML má být.

Žádný univerzální formát vám nezabrání navrhnout nějaké schéma špatně. Špatné formáty ale brání udělat to schéma dobře.

V porovnání třeba s Texem nebo tím Markdownem je tam hromada mechanického datlování.
Zatímco psát jakoukoli malinko složitější stránku na Wikipedii je trivialita a kód je na první pohled krásně čitelný, že? Viděl jste někdy zdrojový kód nějaké stránky na WIkipedii?