Atributy v XML

[Filip Jirsák]

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.

[Reklama]

[listoper]

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.

[kraxna]

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.

[JSH]

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 nebo 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ů.

[Kit]

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 nebo 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á:

Kód [Vybrat] Rozbalit

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

Pokud by to mělo být korektní, tak by to vypadalo takhle:

Kód [Vybrat] Rozbalit

<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}
nebo takhle:

Kód [Vybrat] Rozbalit

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

[Reklama]

[JSH]

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

[Kit]

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.

[Kit]

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

[Franta <xkucf03/>]

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

[Filip Jirsák]

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

[JSH]

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.

[JSH]

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.

[JSH]

Stačí se podívat na to, co se porovnává:

Kód [Vybrat] Rozbalit

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

Pokud by to mělo být korektní, tak by to vypadalo takhle:

Kód [Vybrat] Rozbalit

<user><id>%d</id><name>%s</name></user>
vs.
{"user":[{"id":%d},{"name":"%s"}]}
nebo takhle:

Kód [Vybrat] Rozbalit

<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á).

[Kit]

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

[Filip Jirsák]

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?