Proč se v Javě XML nahrazuje YML?

[gll]

Pokud ale k technologii přistoupíte v pozdějším cyklu, tak komukoliv bez let zkušeností letitá technologie musí přijít jako monstrum - do rozjetého vlaku se dost špatně nastupuje - a začíná se znova s něčím jednoduchým, přehledným, rychlým elegantním, z čehož se za 10-20 let stane monstrum.

Tak proč je Java pořád tak úžasná? Nebobtná, je jednoduchá, přehledná a elegantní. A to není úplně nová.

Jako vtip dobrý. Java je zrovna perfektním ukázkou mého tvrzení - její ekosystém je po cca 20 letech morbidní - desítky knihoven a frameworků jsou legacy, ale stále se aktivně používají (v enterprise prostředí je upgrade až ta poslední věc). Java jako jazyk zůstala jednoduchá, ale o to více se komplikoval její ekosystém. V praxi se asi nepotkáte s tím, že by se programovalo v čisté Javě. Podobný vývoj je vidět i na C# - jelikož si vývoj držel pod palcem Microsoft, tak vývoj nepřipomínal kambrickou explozi, ale tam se zase výrazně bobtnal vlastní programovací jazyk.

Ze nekdo stale pouziva nejake stare ohavnosti ale vubec neni problem javy, ta je, jak rekl predrecnik, stale jednoduchy a elegantni jazyk.
V jave zkratka zalozim novy projekt, do pom.xml dal jenom slusne a overene moderni frameworky co zrovna potrebuju, ze nekde na maven central sedi nejaka hromada stareho desiveho hnoje me vubec nezajima.

A pokud nejsem prase a ani maintainer frameworku neni, upgrady jdou jednoduse.
Minuly tyden jsem na stavajicicm rozdelanem projektu upgradoval Spring Boot prepsanim retezce "1.5.9" na "2.0.5" v pom.xml. Hotovo.

Naopak .Net na bobtnani dojel a .Net Core je prave snaha o setrepani stareho balastu.

používání specializovaných formátů jako XML/YML pro konfiguraci je problém kompilovaných jazyků. V interpretovaných jazycích většinou můžete psát konfiguraci přímo.

[Reklama]

[Kit]

Když se podíváte na zdroják libovolné stránky na Wikipedii, je tam plno nesrozumitelných šablon, parametry se píšou pokaždé jinak a bez nápovědy nenapíšete ani externí odkaz. O co přehlednější a srozumitelnější by ten zdroják byl, kdyby se nepoužíval „jednoduchý“ wiki jazyk, ale „komplikované“ XML.

Kdysi jsem to zkusil přepsat do XML. Čitelnost se razantně zvýšila, hlavně doplněním sémantických značek místo pozičních parametrů. Od té doby používám XML pro zápis textů určených nejen pro HTML, ale i pro jiné účely. Elegantně se tím oddělí data od specifikace formátu zobrazení. Tady bych si rýpnul i do různých prezentačních frameworků (Latte, Twig, ...) které to buď neumí, anebo k tomu vývojáře nevedou.

... logovat strukturovaná data, a pak je případně pro zobrazení člověku hezky zformátovat. Ostatně logování v cloudu už přesně k tomuhle vede, protože logy z desítek strojů už nejde zpracovávat tak, že si budete pročítat textové soubory.

Zkusil jsem logování ve stylu jeden záznam - jeden řádek JSON. Bylo to krásně čitelné a poradilo si to i s non-ASCII. Úplně stejně by to šlo v XML.

Použít pro REST JSON má vlastně jedinou výhodu – snadno se s tím pracuje v prohlížečích, protože prohlížeče nemají rozumné nástroje pro práci s XML (přestože pracují s DOMem, který je přirozenou reprezentací XML).

JSON je formát, který je vhodný pro komunikaci s aplikací v Javascriptu a odvozených jazycích. Pro jiné účely by se používat neměl.

... a nedochází jim, že ta složitost není v jazyce, ale v těch dokumentech, a že pro zápis složitějších dokumentů prostě je potřeba určitá robustnost, která u jednoduchých dokumentů skutečně bude trochu překážet.

Ta robustnost XML nemusí překážet, pokud je správně uchopena. Komu vadí XML, ten by si měl pořídit editor s formulářem generovaným z XSD nebo RelaxNG. Data uložená do takového formuláře se zapíší do validního XML. V čem je problém? Chtějí snad na editování konfigurace používat Notepad bez jakékoli možnosti validace?

XML by pomohla jedna věc – vydat novou verzi, ve které bychom se vykašlali na DTD a uživatelské entity, a ponechalo by se tam to, co se dnes z XML reálně používá. Problém je, že mnozí by chtěli nejspíš vyházet i XML instrukce a/nebo CDATA, na čemž se nejspíš nikdo neshodne, tak se do toho nikdo raději ani nepouští.

Tady nesouhlasím. DTD je sice přežitkem, ale proč se zbavovat uživatelských entit? XML instrukce a CDATA většina uživatelů asi nezná a je ochotna je postrádat ale když je nepoužijí, tak jim ani nepřekáží.

[Kit]

používání specializovaných formátů jako XML/YML pro konfiguraci je problém kompilovaných jazyků. V interpretovaných jazycích většinou můžete psát konfiguraci přímo.

Proč by kompilovaný jazyk nemohl načítat XML/JSON/YAML/INI pro konfiguraci?

[Oooo]

To jsou proste problemy modernich (hipsterskych, bukanyrskych) programatoru, designeru a dalsich lopat, kterym nestaci bitovy proud :-)

Vezmi jakykoliv textovy format, udelej bzip2, nebo efektivnejsi kompresi
A mas vyreseno setreni s daty.

[senior]

Pokud ale k technologii přistoupíte v pozdějším cyklu, tak komukoliv bez let zkušeností letitá technologie musí přijít jako monstrum - do rozjetého vlaku se dost špatně nastupuje - a začíná se znova s něčím jednoduchým, přehledným, rychlým elegantním, z čehož se za 10-20 let stane monstrum.

Tak proč je Java pořád tak úžasná? Nebobtná, je jednoduchá, přehledná a elegantní. A to není úplně nová.

Jako vtip dobrý. Java je zrovna perfektním ukázkou mého tvrzení - její ekosystém je po cca 20 letech morbidní - desítky knihoven a frameworků jsou legacy, ale stále se aktivně používají (v enterprise prostředí je upgrade až ta poslední věc). Java jako jazyk zůstala jednoduchá, ale o to více se komplikoval její ekosystém. V praxi se asi nepotkáte s tím, že by se programovalo v čisté Javě. Podobný vývoj je vidět i na C# - jelikož si vývoj držel pod palcem Microsoft, tak vývoj nepřipomínal kambrickou explozi, ale tam se zase výrazně bobtnal vlastní programovací jazyk.

Ze nekdo stale pouziva nejake stare ohavnosti ale vubec neni problem javy, ta je, jak rekl predrecnik, stale jednoduchy a elegantni jazyk.
V jave zkratka zalozim novy projekt, do pom.xml dal jenom slusne a overene moderni frameworky co zrovna potrebuju, ze nekde na maven central sedi nejaka hromada stareho desiveho hnoje me vubec nezajima.

A pokud nejsem prase a ani maintainer frameworku neni, upgrady jdou jednoduse.
Minuly tyden jsem na stavajicicm rozdelanem projektu upgradoval Spring Boot prepsanim retezce "1.5.9" na "2.0.5" v pom.xml. Hotovo.

Naopak .Net na bobtnani dojel a .Net Core je prave snaha o setrepani stareho balastu.

+1

[Reklama]

[gll]

používání specializovaných formátů jako XML/YML pro konfiguraci je problém kompilovaných jazyků. V interpretovaných jazycích většinou můžete psát konfiguraci přímo.

Proč by kompilovaný jazyk nemohl načítat XML/JSON/YAML/INI pro konfiguraci?

je pohodlnějěí psát konfiguraci ve stejném jazyce jako aplikace.

[Filip Jirsák]

Tady nesouhlasím.

Vždyť jsem to psal, že se stejně lidi neshodnou, co z těch málo používaných věcí z XML vyhodit :-)

DTD je sice přežitkem, ale proč se zbavovat uživatelských entit? XML instrukce a CDATA většina uživatelů asi nezná a je ochotna je postrádat ale když je nepoužijí, tak jim ani nepřekáží.

Na XML instrukce i CDATA občas narazím. Uživatelské entity jsem v praxi ještě použité neviděl. Zbavoval bych se jich proto, že velmi komplikují XML parser a otvírají cestu pro různé XML injection chyby. Navíc tedy pokud vím, jsou definované v DTD, takže když se chci zbavit DTD, musím se zbavit i jich – pokud je nechci nějak komplikovaně zavádět jinak. Navíc zrušením DTD a uživatelských entit by se docílilo toho, že XML dokument by byl vždy samostatná plnohodnotná entita, nezávisel by na ničem dalším. (Trochu by to kazily výchozí hodnoty v XML schématu, ale to je věc o úroveň výš, XML dokument jde rozparsovat i bez nich.)

[Kit]

používání specializovaných formátů jako XML/YML pro konfiguraci je problém kompilovaných jazyků. V interpretovaných jazycích většinou můžete psát konfiguraci přímo.

Proč by kompilovaný jazyk nemohl načítat XML/JSON/YAML/INI pro konfiguraci?

je pohodlnějěí psát konfiguraci ve stejném jazyce jako aplikace.

Viděl jsem to v praxi a byly s tím jen potíže, protože konfiguraci musel upravovat vývojář.

Právě u Javy je významný problém v tom, že nerada spolupracuje s jinými jazyky. Snaží se všechno zvládat sama. Jenže jaký význam má psaní konfigurace např. právě v té Javě?

[Kit]

DTD je sice přežitkem, ale proč se zbavovat uživatelských entit? XML instrukce a CDATA většina uživatelů asi nezná a je ochotna je postrádat ale když je nepoužijí, tak jim ani nepřekáží.

Na XML instrukce i CDATA občas narazím. Uživatelské entity jsem v praxi ještě použité neviděl. Zbavoval bych se jich proto, že velmi komplikují XML parser a otvírají cestu pro různé XML injection chyby. Navíc tedy pokud vím, jsou definované v DTD, takže když se chci zbavit DTD, musím se zbavit i jich – pokud je nechci nějak komplikovaně zavádět jinak. Navíc zrušením DTD a uživatelských entit by se docílilo toho, že XML dokument by byl vždy samostatná plnohodnotná entita, nezávisel by na ničem dalším. (Trochu by to kazily výchozí hodnoty v XML schématu, ale to je věc o úroveň výš, XML dokument jde rozparsovat i bez nich.)

Uživatelské entity používám jako makra. Jak bys chtěl do XML entit injektovat chyby? To by neprošlo validací. Uživatelské entity se definují zpravidla přímo v dokumentu, ale je mnoho užitečných externích DTD, které obsahují entity vhodné pro určité obory činnosti.

Takže nelze zrušit ani DTD. Vlastně si ho můžeš zrušit tak, že ho nebudeš používat. XML dokument může být samostatnou plnohodnotnou entitou, stejně jako YAML/JSON/INI.

[z]

Za roky praxe jsem jeste nevidel hezky/prehledny/citelny XML dokument, ktery by mel vice jak ~30 radku. Komentare nekomentare. DTD je hezka vec, ale jde zit bez toho, XSLT - probuh proc?! To snad nikdo nemuze nazvat featurou, tuhle vec bych rad zapomnel. XPath - no dobre, to je uzitecne, ale kolikrat jsem to potreboval za poslednich ~5 let? 1x?

A v neposledni rade - proc se ucit dalsich 10 veci, kdyz muzu znat programovaci jazyk a jednoduchou sytaxi pro konfigurace? ... Tohle je asi odpoved na to "proc". Dnes se programuje jinym zpusobem - rychle neco vyblejt a jit dal, ne resit den XMLko.

(S vaznejsim programovanim jsem zacal zacatkem milenia, proto mne rozhodne nelze narknout z nejakeho hipsterismu)

[Filip Jirsák]

Uživatelské entity používám jako makra.

Podle mne to za ty problémy nestojí. Místo maker se dá použít XSLT.

Jak bys chtěl do XML entit injektovat chyby? To by neprošlo validací. Uživatelské entity se definují zpravidla přímo v dokumentu, ale je mnoho užitečných externích DTD, které obsahují entity vhodné pro určité obory činnosti.

„Neprošlo validací“ znamená, že už to muselo projít parserem. Právě ty externí DTD jsou obrovské bezpečností riziko.

Takže nelze zrušit ani DTD.

Já myslím, že lze. V pohodě bych se obešel bez všeho, co DTD umožňuje, nikdy jsem to nepotřeboval a neviděl použité.

Vlastně si ho můžeš zrušit tak, že ho nebudeš používat. XML dokument může být samostatnou plnohodnotnou entitou, stejně jako YAML/JSON/INI.

Může a většinou je. Ale nedá se na to spolehnout. Když budu psát XML parser, musím počítat s DTD. Když budu používat parser, musím řešit, jak se zachovat k případným externím DTD. Když budu psát webovou službu (ať na straně serveru nebo klienta), musím řešit, co když v tom XML někdo použije DTD, nebo dokonce externí DTD. Ano, když tu webovou službu definuju, můžu do podmínek navíc někde textově napsat, že se nesmí používat DTD. Ale bylo by fajn, kdyby si tohle nemusel definovat každý zvlášť a každý trochu jinak, ale kdyby stačilo napsat, že se používá XML 2.0.

[Filip Jirsák]

Za roky praxe jsem jeste nevidel hezky/prehledny/citelny XML dokument, ktery by mel vice jak ~30 radku.

Řekl bych, že jste na jeden koukal zrovna při psaní toho komentáře. HTML5 se dá serializovat i jako XHTML. Dokument si přece nemusíte prohlížet jen ve zdrojové podobě – dokumenty z LibreOffice nebo MS Wordu si také asi neprohlížíte ve zdrojáku, stejně jako HTML.

XSLT - probuh proc?! To snad nikdo nemuze nazvat featurou, tuhle vec bych rad zapomnel.

XSLT je výborná věc, můžete deklarativně popsat transformaci jednoho formátu XML dokumentu do jiného, a nemusíte to pracně programovat v nějakém imperativním jazyce. Máte třeba výstup z relační databáze jako XML, a pomocí XSL transformací z toho nasekáte HTML5 webovou stránku, FO a to převedete na PDF, MS Excel a LibreOffice a pro chudé z toho vyrobíte CSV. Porovnejte si to s JSONem, kde se to pořád přesypává ručně z jednoho JSONu do jiného.

XPath - no dobre, to je uzitecne, ale kolikrat jsem to potreboval za poslednich ~5 let? 1x?

Já několikrát měsíčně.

rychle neco vyblejt a jit dal, ne resit den XMLko.

Kdyby se v té YAML konfiguraci třeba Spring Bootu řešilo to samé, co se dříve řešilo XML pro Spring (Core), nebudete ten YAML řešit den, ale měsíc. Což ale nebyla chyba XML, ale jeho nevhodného použití (což není výtka, tehdy to moc lépe nešlo). Všimněte si, že abyste mohl tu konfiguraci třeba Spring Bootu dneska pohodlně editovat, museli pro to autoři IDE naprogramovat podporu, která rozumí tomu formátu souboru, rozumí Springu a umí to propojit. Přitom editory XML umí tohle s pomocí XML schémat dávno. Takže na straně editoru by se nemuselo řešit nic, a na straně Springu jenom umět z toho datového modelu konfigurace v Javě vygenerovat XSD. A to už můžou používat ty editory, můžou to používat validátory, může se to použít při generování dokumentace. Ale proč používat nástroje, které tu jsou už patnáct let, když to může celé napsat znova a pro tenhle jeden konkrétní případ, že…

[Kit]

Uživatelské entity používám jako makra.

Podle mne to za ty problémy nestojí. Místo maker se dá použít XSLT.

XSLT má trochu jiné použití a nedá se nacpat do stejného dokumentu. Je fakt, že když je to umožněno, tak se dá udělat injekce.

Jak bys chtěl do XML entit injektovat chyby? To by neprošlo validací. Uživatelské entity se definují zpravidla přímo v dokumentu, ale je mnoho užitečných externích DTD, které obsahují entity vhodné pro určité obory činnosti.

„Neprošlo validací“ znamená, že už to muselo projít parserem. Právě ty externí DTD jsou obrovské bezpečností riziko.

Mezitím jsem si to našel a vyzkoušel přes xmllint.
https://en.wikipedia.org/wiki/XML_external_entity_attack
Zřejmě se s tím dají dělat docela kouzla a jedinou skutečnou obranou bude asi sandbox. Vyzkouším ještě jiné parsery a parametry.

Vlastně si ho můžeš zrušit tak, že ho nebudeš používat. XML dokument může být samostatnou plnohodnotnou entitou, stejně jako YAML/JSON/INI.

Může a většinou je. Ale nedá se na to spolehnout. Když budu psát XML parser, musím počítat s DTD. Když budu používat parser, musím řešit, jak se zachovat k případným externím DTD. Když budu psát webovou službu (ať na straně serveru nebo klienta), musím řešit, co když v tom XML někdo použije DTD, nebo dokonce externí DTD. Ano, když tu webovou službu definuju, můžu do podmínek navíc někde textově napsat, že se nesmí používat DTD. Ale bylo by fajn, kdyby si tohle nemusel definovat každý zvlášť a každý trochu jinak, ale kdyby stačilo napsat, že se používá XML 2.0.

Proč psát vlastní parser XML, když je jich docela slušný výběr? Načítání externích DTD vypneš při volání parseru.

Tohle je však docela hezké:

Kód: [Vybrat]

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ELEMENT root ANY>
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>
xmllint --noent to krásně rozbalí

[Kit]

Za roky praxe jsem jeste nevidel hezky/prehledny/citelny XML dokument, ktery by mel vice jak ~30 radku. Komentare nekomentare. DTD je hezka vec, ale jde zit bez toho, XSLT - probuh proc?! To snad nikdo nemuze nazvat featurou, tuhle vec bych rad zapomnel. XPath - no dobre, to je uzitecne, ale kolikrat jsem to potreboval za poslednich ~5 let? 1x?

Kouknul jsem se na XML, které jsem nedávno dělal. Má něco přes 500k řádek, na čitelnosti mu to nijak neubírá. Komentáře tam nejsou, protože dobře navržené XML je samopopisné.

XSLT je skvělý jazyk. Deklarativně napíšeš, jak má vypadat výsledek. Když použiješ metodu pull, tak je to fakt na zbláznění. Proto se má používat push, který vypadá elegantně. Měl by ses obejít bez podmínek a cyklů, pak je to správně cool.

XPath je elegantním nástrojem pro výběr záznamů z XML. Používám ho velmi často a ve spojení s XSLT je to paráda.

Ještě nebylo zmíněno XQuery, které používám zejména při vyhodnocování testů. Umí toho sice méně než XSLT, ale je jednodušší - skoro jako SQL.

A v neposledni rade - proc se ucit dalsich 10 veci, kdyz muzu znat programovaci jazyk a jednoduchou sytaxi pro konfigurace? ... Tohle je asi odpoved na to "proc". Dnes se programuje jinym zpusobem - rychle neco vyblejt a jit dal, ne resit den XMLko.

Jakých dalších 10 věcí? Tohle vše je XML, které je podporováno většinou programovacích jazyků. Syntaxe je velmi jednoduchá, bariérou je jen deklarativní přístup různých nástrojů. XSLT se svým chováním dost podobá zde propagovanému Haskellu, i když syntaxe je jiná. Pro vývojáře, který píše strukturovaně nebo objektově, je to docela obtížně stravitelné, ale když se dostane přes "aha", tak zjistí, že to zas tak obtížné není.

Konfigurace se načítá jednoduše: Natáhneš si XML do DOMu a pak si přes getElementById(), getElementsByTagName() nebo přes XPath vytáhneš ten node (resp. jejich seznam), který tě zajímá. Ještě lepšího výsledku však dosáhneš použitím metody push, která je efektnější a efektivnější.

[technomaniak]

Přinejmenším na Java plaformě se v posledních letech začalo omezovat používání XML souborů ve prospěch psaní přímo v Javě - vývojáři si asi uvědomili, že proč programovat v XML, když to můžeme dělat přímo v Javě.

Já ho sice nepoužívám(jedu na XML) ale vypadá mnohem jednodušší na naučení. Za mě je nevýhodou XML jeho rozsáhlost, různé typy XML, specifikace schémat, atd.. stal se prostě moc složitým. Takže zcela rozumím, proč se u XML učit 100x  více( a tedy i mnohem déle) + pamatovat si to, se lidem zjevně nechce. např. ta kniha od Herouta je dobrá, ale má cca 200+ stránek a plně nepokrývá vše co XML obnáší, zatím co YML (např. https://dzone.com/articles/using-yaml-java-application ) je mnohem, mnohem jednoduší a znakové sady taky podporuje(http://yaml.org/spec/current.html#id2513364).

Tady si myslím, že se IT sektoru vrací to co samo rozjelo. Inovace, inovace, inovace -> honba za stále lepšími řešeními se stala závislostí po změně. Když se změna neděje, tak to hloupí vnímají jako mrtvé a tudíž špatné. ( řečeno slangem ulice = jste feťáci závislí na změnách )