Proč se v Javě XML nahrazuje YML?

[Filip Jirsák]

Za mě je nevýhodou XML jeho rozsáhlost, různé typy XML, specifikace schémat, atd.. stal se prostě moc složitým.

Jaké různé typy? K psaní schémat vás nic nenutí, je to jenom možnost.

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.

To bych to 100× více chtěl vidět. Pro psaní XML stačí umět napsat element a atribut. S YAML stejné složitosti dosáhnete, když se naučíte psát víceřádkové hodnoty – a pořád ještě zbývají seznamy, odsazení…

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

Jenže to porovnáváte dvě úplně nesouměřitelné věci. Používat XML stejně, jako používáte YAML, není složitější, spíš naopak. A vedle toho pak máte pro XML spoustu nástrojů, které můžete použít, když se vám to hodí, ale používat je nemusíte.

[Reklama]

[Kamil Podlešák]

YAML získává na oblíbenosti, protože je to kompromis. Obsahuje totiž věci, které v JSON zoufale chybí a činí ho velmi nepraktickým pro konfigurační soubory - komentáře a víceřádkové texty (na více řádkách, samozřejmě).
Má samozřejmě i další feature, ale ty se moc nepoužívají (např. tagy jsem v praxi nikde neviděl) - právě z toho důvodu, že se používá jako náhrada za JSON.

Porovnání s XML je trochu mimo - XML je "značkovací" (markup) formát, primárně určený pro text jehož části jsou nějak označeny (takže třeba XHTML). Použití pro konfigurační soubory je méně praktické jak pro lidi, tak pro zpracování v programu. Samozřejmě, zvykli jsme si (koneckonců, pořád lepší než ini soubor).

[JS]

Skoda, ze skoro nikdo nezna Dhall. To je skutecna inovace v konfiguracnich jazycich. Prehlednost YAMLu za mensi celkovou slozitost, overitelnost schematu lepsi nez u XML a mnohem vetsi programovatelnost jako bonus.

[Janci]

V JSON-e je jasné, či je daný prvok objekt ({}), pole ([]) alebo hodnota. To sa dobre mapuje na bežné dátové typy v aplikácií.

V XML bez schémy nikto nevie, či daný element tam bude vždy len raz alebo sa môže opakovať. A schéma často chýba, alebo je taká obecná, že to nepomôže. Tiež bez schémy človek nevie, či nová vlastnosť bude reprezentovaná ako atribút alebo element.

K JSONu sa dá pristupovať ako k Map-e, sú tam metódy ako getOrDefault, testovanie na existenciu je jednoduché a kód je prehľadný. Potom práca s DOMom je utrpenie. Iterovať cez NodeList boilerplatové peklo.

[j]

...

To je uplne jednoduchy, je to neustale se opakujici schema ... nejdriv nekdo prijde s jednoduchym a primitivnim formatem, ktery ale naprosto neresi co kde muze byt. Pak se format zacne rozsirovat upravovat a vylepsovat, az je tak slozitej, ze sice umi uplne vse, ale nikdo tomu nerozumi, a tak zas nekdo znova prijde s tim uzasne jednoduchym formatem, kterych tu uz je asi 158, aby se zase dalo neco rozsirovat a vylepsovat.

Typickej priklad je prave xml, ktery ma definovany jak popis (dtd) tak pripadny zpracovani (xsl) atd atd ... ale neznam moc lidi, kteri by tusili jak to funguje.

Takze kdyz se rozhlidnes, najdes desitky a desitky vsemoznych uzasnych a zcela nekompatibilnich formatu urcenych k vymene dat, abys nakonec skoncil u toho csvcka, i kdyz ani to se trebas soudruzi z M$ dodnes nenaucili otevrit.

[Reklama]

[j]

...XML je "značkovací" (markup) formát, primárně určený pro text...

Ehm nikoli, xml je format urceny primarne pro data, s textem to nema temer vubec nic spolecneho. Konfigurace v xml naopak narozdil do jinych moznosti umoznuje spoustu veci velice zjednodusit, a predevsim, pokud je to solidne navrzeno, da se to bez problemu cist/zapisovat libovolnym textovym editorem, a zaroven libovolnym nastrojem ktery umi prave s xml pracovat.

Jediny problem ktery muze vyvstat je ten, ze zpracovat nejaky prosty custom text umi kazda aplikace na 1 radku kodu, kdezto na to xml potrebuje knihovnu. Stejny problem ma ale naprosto libovolny format krome toho prosteho textu. Naopak, konfiguracne slozitejsi aplikace se pri tom prostem textu muze snadno dostat do situace, kdy je vice kodu jen prave zpracovani konfigurace, nez vlastni funcionalita.

[oss]

Asi som z inej planety, ked povazujem XML za zrely a citatelny format (samozreme da sa sprasit ale to vsteko).
JSON-u pre konfiguraciu zufalo chybaju komentare a takisto akekolvek standardy (JSON schema je stale draft a nie je jedna).

Tomu co vymslel YAMl by som zlamal prsty, na 3-riadkove konfigy je to pohoda, ale ked sa clovek sekne v jednej medzere v stranovom YAML-y tak sa to uzasne hlada a hlavne na jeho pisanie treba pravitko.

Zatial co si clovek v XML napise schemu a ta ide na vstekych platformach a IDE-ckach, s XML-kom vie pracovat kazdy rozumny jazyk. 

[MarSik]

Taky proti XML nic nemám, ale psát ho ručně není zrovna příjemné (obzvláště když se používají jmenné prostory). IDE s doplňováním a podporou DTD pomáhá neskutečně.

Json i yaml také mají svoje užití, ale dost často narážím právě na neexistenci obecně akceptovaných ekvivalentů pro validaci, xpath a xslt. A také na složité parsery pro data, které by s XPath "zhubly" o 90% kódu.

[Kit]

V JSON-e je jasné, či je daný prvok objekt ({}), pole ([]) alebo hodnota. To sa dobre mapuje na bežné dátové typy v aplikácií.

V XML je to jasné také. Všechny elementy jsou součástí nějakého seznamu. Objekt poznáš podle atributu "id", na který se můžeš přímo odkazovat. Navíc můžeš k hodnotě přidat i jednotku a další atributy, což je u JSONu docela problém.

V XML bez schémy nikto nevie, či daný element tam bude vždy len raz alebo sa môže opakovať. A schéma často chýba, alebo je taká obecná, že to nepomôže. Tiež bez schémy človek nevie, či nová vlastnosť bude reprezentovaná ako atribút alebo element.

Pokud si XML někdo definuje pro sebe, tak schéma dělat nemusí. Pokud ho však chce prezentovat jako rozhraní, měl by ho i specifikovat. Může k tomu využít DTD, XSD nebo RelaxNG.

K JSONu sa dá pristupovať ako k Map-e, sú tam metódy ako getOrDefault, testovanie na existenciu je jednoduché a kód je prehľadný. Potom práca s DOMom je utrpenie. Iterovať cez NodeList boilerplatové peklo.

XML umí totéž - stačí se jen podívat, jak se to dělá. Vůbec nemusíš iterovat přes NodeList - stačí použít metodu getElementById() a dostaneš přímo požadovaný Node. Místo boilerplates si napíšeš jednoduchý adaptér, do kterého můžeš implementovat i coalesce(), pokud ho potřebuješ.

[Kit]

Taky proti XML nic nemám, ale psát ho ručně není zrovna příjemné (obzvláště když se používají jmenné prostory). IDE s doplňováním a podporou DTD pomáhá neskutečně.

Json i yaml také mají svoje užití, ale dost často narážím právě na neexistenci obecně akceptovaných ekvivalentů pro validaci, xpath a xslt. A také na složité parsery pro data, které by s XPath "zhubly" o 90% kódu.

To je právě ono. Vývojáři chtějí editovat prostý text. Pro jednoduché konfigurace tedy zvítězí YAML. Pokud má víc než 2 úrovně zanoření, začínají problémy s přehledností. JSON na tom není o mnoho lépe. Stejně by se víc než 2 úrovně neměly používat, obvykle ani nejsou potřebné. Ostatně na většinu konfigurací stačí i formát INI, který je stále hojně používán.

XPath a XSLT jsou často nepochopené, ale přitom geniální technologie. Kdo pochopil Haskell, pochopí i tohle, protože sémanticky je to hodně podobné.

[BoneFlute]

Skoda, ze skoro nikdo nezna Dhall. To je skutecna inovace v konfiguracnich jazycich. Prehlednost YAMLu za mensi celkovou slozitost, overitelnost schematu lepsi nez u XML a mnohem vetsi programovatelnost jako bonus.

To bude tím, že když už ho někdo zmíní, tak o něm nic neřekne. Ani link neuvede. Já jsem na něj před časem narazil. A na Haskellovskou akci tedy dokumentace na zabití.

[BoneFlute]

Já jsem na něj před časem narazil. A na Haskellovskou akci tedy dokumentace na zabití.

Ah, pardon, trochu jsem se unáhlil. Ten problém nebyl s tím, že by byla špatná dokumentace, jako spíš s tím, že mi to nešlo nainstalovat, tak jsem se naštval. Takže asi spíše moje chyba.

[Petr]

Vzdyt ty formaty maji uplne jina vyuziti. Delat z jsonu cfg soubor je stejna pitomost jako pouzivat yaml na vymenu dat mezi systemy.

[JS]

Vzdyt ty formaty maji uplne jina vyuziti. Delat z jsonu cfg soubor je stejna pitomost jako pouzivat yaml na vymenu dat mezi systemy.

Pouzivat XML nebo JSON na vymenu dat mezi systemy je zverstvo. Spravne by se melo pouzivat neco jako PB nebo CBOR.

Ale ja to taky delam, samozrejme, duvodem je predevsim Javascript (ktery jeste donedavna neumel nic lepsiho).

[Kit]

Pouzivat XML nebo JSON na vymenu dat mezi systemy je zverstvo. Spravne by se melo pouzivat neco jako PB nebo CBOR.

V tom souboru CBOR nikde nevidím sémantické značky. Místo takových non-human-readable formátů je jednodušší použít textový formát s kompresí při přenosu.