Jak mě naštvaly XML dokumenty

21.11.2013 18:05 | Přečteno: 3059× | Linux | poslední úprava: 21.11.2013 19:16

Nevím jestli jsem sám, ale jak tak sem tam slýchám, tak úplně ne, kterého někdy vytáčí xml dokumenty. Ne že bych měl něco proti XML dokumentům obecně, ale některé užití, za určitých okolností je protivné.

A protivné je to tehdy, pokud se jedná o konfigurační soubory a chci si něco zjistit-vytáhnout v normálním malučkém skriptíku. Samozřejmě lze použít některé knihovny a není jich málo — což je možná také „potíž“.

No, a oni (ti zlí xml dokumenti) mě dohnali k tomu, udělat si něco na úrovni bash-e. Pokud to ovšem mělo být jednoduché, nešlo se na „ně“ dívat, jak na XML strukturovaný dokument, ale zpracovávat je trochu jiným „jednodušším způsobem“.

Chtěl jsem udělat jen něco jako transformační script, co z toho udělá něco čitelného, ale pak mě to zaujalo, tak jsem tam ještě něco doplnil, z čehož vznikl takový, ne úplně čistý kód, nicméně vypadá, že funguje. By-design si neporadí se smíšeným kontejnerem (obsahující text i další tagy), nicméně na kulturní XML dokumenty funguje, nebo se tak minimálně tváří.

Funguje to tak, že zlý dokument se prochází a uchovává se jen informace „co“ se našlo minule a „co“ teď a dle toho se to sype ven (jako: »minule tag, nyní obsah −> vypiš to«).
Cesta se vypisuje tečkami oddělená (ve výchozím stavu) a hodnota se vypíše za „rovná se“, pokud se jedná o atribut, tak je uvozen „zavináčem“ a komentář „křížkem“ (včetně DOCTYPE). Hodnota má napraveny HTML entity & > < ", všechny '\' jsou zdvojeny a všechny nové řádky jsou jako '\n', tedy výpis každé entity je jednořádkový (a běžným echo-em lze hodnotu vypsat, tak jak má být).

Ve výsledku to znamená že mám(e) rozumně zpracovatelný výpis typu key=value.
No a jak jsem uvedl, „zaujalo mě to“, tak jsem doplnil jednoduchá přepínače

• -F = filtr na cestu (klíč)
• -N = filtr jen na N-tý výskyt cesty (a ukončení čtení souboru)
• -T = nevypisuj tag-y
• -A = nevypisuj atributy
• -V = nevypisuj cestu/klíč, ale jen hodnotu (proč to není 'K' — nevím)

Nejen díky tomu, ale díky i předčasné (a zbytečné) optimalizaci, je hlavní smyčka v kódu de-facto 3× (bez -F a -N nejjednodušší, bez -N jednoduchá, s -F a -N „vše řešící“), ale aspoň je veselo.

No a ve výsledku už s tím lze příjemně pracovat, ne že by z některou knihovnou nešlo taky a i líp, ale toto je nezávislé maličké. Nicméně vzhledem ke způsobu zpracování dokumentu, se to spíš musí otestovat, než revizí kódu prohlásit 'OK'.

Na ukázku jsou přiloženu dva, snad lehce pochopitelné, obrázky (aby si to náhodou někdo nekopíroval do schránky :) ), kde jsem něco vyčetl z nějaké policy a pak z definice VM.

Opět se zopakuji: Protože zde nelze vložit přílohy, tak je to tu

       

Obrázky

Komentáře

[Petr Masopust]

Myslim, ze mas neco jako subset xpath... Btw treba xmllint a dalsi podobne nastroje by mely zvladat to same i z cli.

[Šangala]

Však to píšu, že toho existuje roj...

[backinabag]

y

[Šangala]

Dík - to bolelo.

[Semo]

Svojho casu som si na netrivialnu strojovu upravu velkych XML dokumentov napisal bashove skripty, ktore rozobrali XML do stromovej struktury na filesysteme a spatne to dokazali identicky poskladat (so zachovanim poradia elementov na rovnakej urovni). Podmienene upravy stromu, mazanie/vkladanie podstromov atd.je potom uz easy. Potreboval som to na dokumenty, ktore neobsahovali CDATA, takze co element to adresar, co atribut to subor s hodnotou ako obsahom suboru, nazvy prefixovane cislami na zachovanie poradia elementov.

V tom rozbalenom stave sa to lahko prechadzalo beznymi nastrojmi, v com je aj len cisty bash velmi dobry. Path-expansion je mozna zbran a bash-4 wildcard ** tiez. Velke dokumenty to chce spracovavat na ramdisku, inak sa disk umlati. Pre vseobecne pouzitie by som musel domysliet reprezentaciu CDATA a komentarov (asi cez vyhradeny nazov suboru), ale pre to pouzitie to stacilo.

[__dark__]

Tak timto u me vyhrals prvni cenu ve volbe toho nejdebilnejsiho nastroje na reseni daneho problemu a zminka o velkych souborech a ramdisku tomu nasazuje korunu:)

[xkucf03]

Svojho casu som si na netrivialnu strojovu upravu velkych XML dokumentov napisal bashove skripty, ktore rozobrali XML do stromovej struktury na filesysteme a spatne to dokazali identicky poskladat (so zachovanim poradia elementov na rovnakej urovni).

Tohle už mě taky napadlo – chtěl bych to ale jednou implementovat jako FUSE souborový systém, XML by to upravovalo v přímém přenosu (po každém zápisu do souboru), umožnilo by to editaci libovolných XML dokumentů a ještě by je to mohlo online validovat proti XSD nebo jinému schématu (nešlo by některé soubory zapsat, dokud by neměly platný obsah – např. číslo, datum, regulární výraz).

[Semo]

Musis nejak udrziavat poradie surodencov. A mat moznost moznost vkladat na presne miesto medzi nimi. Niektore XML formaty mozu vyuzivat aj poradie elementov na tej istej urovni.

[xkucf03]

jj, tohle by se muselo řešit nějak v názvech souborů¹ nebo přes rozšířené atributy.

• element = adresář s názvem pořadí_názevElementu
• atribut = soubor s názvem @názevAtributu
• textový uzel = soubor s názvem pořadí_cokoli

CDATA by se dalo označit pomocí rozšířených atributů nebo nějak zakódovat do názvu souboru.

A pak nějak ošetřit jmenné prostory – v kořenovém adresáři by mohl být soubor s jejich mapováním na prefixy a případně by je šlo kódovat do názvů souborů.

A pak půjde jako XML editor používat MC

_{[1] např. pokud název bude obsahovat znak „_“, tak to před jeho prvním výskytem bude pořadí a to za ním bude název elementu}

[Šangala]

Toto jsem spíš dělat s opačným cílem, aby to bylo co nejjednodušší a nejmíň náročné a nezávislé, právě pro použití u konfiguráků a jim podobným, kde je použití XML z pohledu jednoduché správy/administrace sporné.

[xkucf03]

Převádíš XML dokumenty na výpis typu key=value, abys je pak mohl grepovat? To mi přijde, jako kdybys nadiktoval dopis sekretářce, ta ho vytiskla, naskenovala, prohnala ORCkem, vytiskla do PDF a odfaxovala přes VoIP virtuálním faxem.

P.S. přílohu dej do komentáře, ať je to na jednom serveru společně se článkem a neztratí se to.

[Šangala]

Ten postup je myslím špatně, nevidím paralelu vysvětli. (Ten grep není třeba).

PS: To už jsem kdysi udělal, ale teď čekám a budu čekat, že „někdo“ doplní možnost přidat přílohu ke článku

[pavlix]

Paralela není potřeba. Franta miluje XML, tudíž převádění XML na cokoli jiného považuje za zbytečnou degradaci.

[Šangala]

Jo-jo, láska je druh fanatismu, takže jistá zaslepenost je na místě…

[marbu]

Achjo. Pro rychlé dotazování lze použít xpath. A pro složitější operace je tu XQuery nebo xslt. Takzě ne cela chápu, o co se snažíš, když pro ně standardní konzolové nástroje.

Ukázka dotazování přes xpath (výsledek dotazu jde na stdout, keci okolo na stderr):

$ xpath domain.xml 'string(/domain/devices/interface/mac/@address)'
Query didn't return a nodeset. Value: 24:42:53:21:52:45
$ xpath domain.xml '/domain/memory/text()'
Found 1 nodes:
-- NODE --
131072

Na fedoře je v balíčku perl-XML-XPath.

Nebo xmlstarlet: XML z příkazové řádky.

[xkucf03]

+1

[Šangala]

Achjo. Nevěděl jsem, že je to tak jednoduché.

Odpověď na otázku „o co s snažíš?“ bude mít velký průnik s odpovědmi na otázku „proč neexistuje jen jedna knihovna?“

Ale konkrétně jsem se snažil/snažím vyřešit třeba: Když ten nebo jiný balíček nemáš? (Konkrétně třeba PartedMagics) nebo nemůžeš stahovat balíčky). Nebo nechceš pro script dohazovat závislosti kvůli prkotině?

[pavel]

Taky to někomu přijde divné - vymyslí se XML - "aby to bylo přehlednější a jednodušší" -> vymyslí se nástroj(e) na převod z XML -> "aby to bylo přehlednější a jednodušší"?

[Hlustmisihak]

No jo, ale kdo řekne kdy a kde a co je prehlednejsi a jednoduší.

[marbu]

Jen pro doplnění, xpath podpora je treba i primo v nástroji xmllint z balíčku libxml2. Konkrétně xmllint --xpath přidali ve verzi 2.7.7. Coz sice porad v tom PartedMagics distru neni, ale v beznych distribucich typu debian zcela jiste bude již naistalovaný.

[pavlix]

Kdysi jsem si jen tak na zkoušku hrál s XSLT. Je to takový hezky standardizovaný způsob jak nad triviální úlohou strávit několik hodin. Když jsem se to už celkem obstojně naučil, začal jse XML radši parsovat pythonem (lxml.etree), a pokud jsem z něj chtěl něco hodně konkrétního, tak klidně i grepem.

[Kvakor]

A pokd by někdo potřeboval to samé, ale v JSON, tak na to existuje jq, které se používá stejně jednoduše.

[Jirka]

Tady bacha na to, že funkce string() z toho vybere jen první výskyt (aneb i XPath má svá temná zákoutí). Prakticky jsou tyhle konverzní operace použitelné jen pro porovnávání.

[User682]

zdravim,

pridam poznamku a zkusenost.

Psat si jakykoli vlastni parser vyzaduje nejake vetsi znalosti a zkusenosti. A TESTY. Hodne testu. Vysledky casto byvaji jine, nez se ocekavalo.

Pokud opravdu potrebujete neco, co umi jen minimalni cast funkcionality nez dostupne xml parsery, tak cesta vede smer gramatiky nebo alespon pres nejaky mezistupen smerem ke gramatikam. Napriklad chcete vypsat jen komentare.

Jako nejlepsi cestu zde kolegove jiz zminili konzolove utility na praci s xml.

Pridam jeden odstrasujici priklad z praxe. Na jednom informacnim systemu byl nasazen jeden priohnuty a ne moc kvalitni parser XML. Dodavatel dodal nejakou beta verzi a dale moc nespolupracoval co se tyce sve komponenty. Pri kazdem nacitani vystupu knihovny s parserem jsme _museli_ xml opravit, aby se dalo zpracovat beznymi nastroji.

Jeste dalsi priklady k danemu tematu: pokud nekdo pisete napriklad vlastni parser CSV souboru, tak mejte na pameti, ze CSV muze mit v sobe i komentare. Nebo, ze pri parsovani html tabulek nemusite mit vse na jednom radku. Regularni vyrazy nespasi vse. Nez resit tisice podminek v cyklu, tak radeji napsat funkci vyhodnocujici a zpracovavajici nejaky prechod.

gf

[Semo]

CSV moze mat v sebe aj delovu gulu, ked pride na to, ale RFC 4180 sa o ziadnych komentaroch nezmienuje. Takze nasrat na autora vlastneho nekompatibilneho rozsirenia.

[JS1]

Bohuzel, ta "nekompatibilni rozsireni" vznikla daleko drive, nez to prislusne RFC. (Jinak absence komentaru je nekdy problem, podobne jako je to problem v JSONu, ale bohuzel pro to univerzalni syntaxe neexistuje.)

[Josef Kufner]

Absence komentářů v JSON je jeho výhodou

[JS1]

Proc?

Me to prijde blbe hlavne v pripade, kdy mam nejaky priklad. Nemoznost napsat do nej komentare je silne limitujici. Nebo kdyz clovek neco zkousi..

[xkucf03]

Třeba konfiguráky bych psal radši snad i v SQL než v JSONu, protože tam komentáře jsou Pokud to má číst a psát člověk, jsou komentáře obrovská výhoda nebo spíš nutnost. A pokud to má číst a psát stroj, tak rozšířit parser o podporu komentářů už nedá moc práce (a na straně generátoru je nemusíš podporovat vůbec).

[xkucf03]

BTW: tahle debata se tu cyklicky vrací, tak jen stručně. Podle mého v sobě JSON kombinuje ty horší vlastnosti různých formátů. Když nemá komentáře, nemusí být ani čitelný/zapisovatelný člověkem – klidně se může použít nějaký binární formát a bude to mnohem efektivnější. Ale když si to hraje na lidsky čitelný text, tak tam komentáře být měly.

[JS1]

Krome absence komentari my jeste v JSONu vadi nutnost davat klice do uvozovek.

Ale nemuzu si nerypnout, kdyz o citelnosti mluvi clovek, co ma (pry) rad XML..

[Michal Vyskočil]

Ale nemuzu si nerypnout, kdyz o citelnosti mluvi clovek, co ma (pry) rad XML.

Ale on napsal

Ale když si to hraje na lidsky čitelný text

[Šangala]

Poznámky k poznámkám:
Vetší znalosti a zkušenosti než co?
Jako nejlepsi cestu zde kolegove jiz zminili konzolove utility na praci s xml. A když je nemáš, tak jaká je cesta?
Odstrašující příklady jsou všude, a toto je jeden z nich (neporadí si s jakýmkoliv XML-kem), XML je super formát, ale na druhé straně je to s ním často jako s obrázkem TIF, každý ho umí zapsat, ale 100% přečíst jakýkoliv, už je pěkná věda.

Ad CSV:
Tok sorry, ale to je krávovina, pokud se bavíme o CSV, tak sice nemá žádnou normu, ale existuje k němu RFC-čko. Pokud soubor není podle něho, tak mu neříkejme CSV (navíc když je oddělené středníkem či tabem , tak už na to není právo ani „jazykově“).
A pokud někdo označí MIME text/csv, tak to musí být „comma“, používajíc " a končící CRLF.

[xkucf03]

Jako nejlepsi cestu zde kolegove jiz zminili konzolove utility na praci s xml.

A když je nemáš, tak jaká je cesta?

Vždyť je to otázka zadání aptitude install libxml-xpath-perl nebo ekvivalentu v jiné distribuci. Pokud to fakt nejde, tak bych to řešil přes Javu, Perl nebo Python (jedno z toho tam mít budeš) a knihovnu přibalenou k programu (v Javě už máš dokonce všechno v JRE).

P.S. neber prosím tyhle komentáře tak, jako že jsi něco zveřejnil a teď ti za to lidi nadávají prostě jen takové zamyšlení, jak bych to řešil já – i když já si taky občas napíšu něco sám, než abych používal hotové programy/knihovny, prostě NIH Každý má občas pocit, že něco udělá jinak, jednodušeji a lépe než ti před ním.

[Šangala]

Zmínil jsem třeba PartedMagics (,který se nám fčul nějak komercializoval) třeba nic rozumného nemá, a mám další dvě distra(, kde minimálně jedno další taky nemá) na flashce, a vždy s tím udělám cokoliv je potřeba na desktopu i na serverech při fyzickém zásahu, a doplnit si tam balíček není úplně tak jak píšeš. Na flashce mám samozřejmě i další skripty a přece neotevřu v daném bodě 'vim' s hláškou najdi sekci bla-bla a opiš atribut 'x' pokud atribut 'y' je 'a' jinak tam napiš 'ahoj', stejně tak pokud třeba mám minimální instalaci nějakého stroje, tak nebudu k vůli každé prkotině instalovat nový balíček a pak při update řešit na co to má vliv, nebo že bych tam dokonce nainstaloval JRE a zahrál si třeba na SAXofon (a přihodil k vůli němu i RAM ).

PS: To tak vůbec neberu (někdy přemýšlím, jestli má odpověď není zbytečně „útočná“, ale politikaření mě nebaví…). Hledal bych tam naprosto to samé a čekal jsem přesně tento typ argumentů a i jsem přemýšlel, jestli mi to za to stojí, ale pak jsem si řekl, že třeba má někdo podobné důvody a třeba mu to pomůže. Už se mi párkrát podařilo udělal něco líp než ti ostatní, kteří si to pak přebrali, takže má smysl to dělat, ale toto je trochu jiný případ.

[JS1]

Jelikoz jsem CSV parser psal, tak prave ta absence (dodrzovane) normy je casto problem. O CSV komentarich nevim, a docela by me zajimalo, jak na to GF prisel (a jakou to ma syntax), ale ze mohou existovat ruzne separatory je pomerne bezne. Napr. CSV se stredniky jsou pomerne casta.

[Šangala]

Jo, pokud dělám parser, tak oddělovač, text ohraničovač, konec řádků, hedaer yes/no a znaková sada musí být (jakože to tak udělám) jako volba, protože to sice pak není CSV i když to někdo tak pojmenuje, ale má to tu strukturu (např. text/tab-separated-values , či ten SSV) a lze to použít.

OT: CSV prostě nemůže být ze středníky, ani dle RFC, ani zkratka jako taková nefunguje

PS: Existence komentářů je pro mně také novinka a není mi jasné, jak se mohou implementovat, podle mně to není možné.

[JS1]

No ja jsem vychazel z toho, co se pise na Wikipedii a tam stredniky zminuji, a i v nasi aplikaci to byl pozadavek.

[Šangala]

Taky jdu s proudem, a nejen při importu, ale i při exportu, to umožňuji. Typicky , ; TAB a dokonce i ohraničení textu " nebo ', ale předvolím , a " při jiné volbě uživatele upozorňuji, nějakou příjemnou formou, že si to bere správné, ale není to standardní CSV. Přece jenom je to nejjednodušší způsob, jak třeba si něco třeba z webu/intranetu/web-aplikace vzít na další zpracování.

[Bystroushaak]

Pak to není CSV, ale DSV, ne?

[pavlix]

Jen pro pobavení...

Nejvíc mě rozesmál takzvaný CSV formát Microsoftu, který je nekompatibilní i mezi stejnými verzemi software, pokud jsou nainstalovány v jiném jazyce. V nějaké verzi Excelu to dotáhli do takové dokonalosti, že instance programu nebyla schopná načíst soubor, který sama exportovala!

[Bystroushaak]

Za Microsoft Office má pár lidí v pekle rezervaci, to je víc než jisté, pokud na světě existuje něco jako nadpřirozeno. I když nejspíš neexistuje, jinak by museli shořet za bílého dne.

Jinak mě nedávno pobavil popis interního formátu Wordu (jen pro otrlé).

[JS1]

Mne je jedno, jak se veci jmenuji.

[Šangala]

Bo jsem se nad tím dokonce zamyslel u psaní a nepřišel jsem na to, tak se ptám, jak je možné u CSV implementovat komentář?

[Bedňa]

Riešenie je jednoduché. Vidím že to používa XML hell, tak to nepoužívam. XML je nezlúčiteľné s ľudskou logikou. Keď budem chcieť nejaké štruktúry, tak použijem syntax like C. Za roky som si nedokázal v Gnome dopátrať vecí čo som chcel zmeniť, zato IceWM s texťákom som mal nastavené za deň. Takže kde sú tie výhody?

[Šangala]

Tak to si v pr..li, bo nemožeš použít ani například virsh či policykit (vybral jsem si je v ukázkách).

[pavlix]

virsh je hrozně zprasené samo o sobě.

[Šangala]

Zprasené je cokoliv co na konfiguraci používá XML zvláště když je to CLI a pokud se do toho ještě zamotají atributy, tak je to už fakt úlet. Asi chápu proč to tak udělali, bo to ty informace „má“ předávat, ale zas na druhé straně, lze očekávat, že bude třeba i „jednoduché“ získávání informací, takže implementace „normálního“ výstupu by nikomu nic neudělalo, nebo případně alespoň definovaná vyšší restrikce nad XML, což je velmi výjimečně k vidění (typu, každý klíč je unikátní, odřádkování je vždy po entitě, použíté jsou jen tyto HTML entity a je to vždy utf-8), ale když je někdo -píp- a použije i atributy, tak je to zabité.

Má to aspoň svobodnou licenci

Ale asi tvůj termín „zprasené“ zahrnuje něco jiného, (já jen bojuji s termíny destroy a undefine, ale snad to časem dám…), tak se ukaž: »proč je to „zprasené“ a čím bys to nahradil?«

[xkucf03]

alespoň definovaná vyšší restrikce nad XML, což je velmi výjimečně k vidění (typu, každý klíč je unikátní, odřádkování je vždy po entitě, použíté jsou jen tyto HTML entity a je to vždy utf-8), ale když je někdo -píp- a použije i atributy, tak je to zabité.

OMG, to jsou kecy. Já zase nemůžu z toho, když někdo spatlá miliontý „jednoduchý textový formát“ a já se musím po milionté učit, jak se oddělují klíče a hodnoty, jestli jsou na koncích řádků středníky, jak se píší komentáře, jestli jsou hodnoty v uvozovkách a jak a jestli jsou tam struktury, jestli se používají třeba složené závorky, nebo jednoduché nebo nějaká obskurní parodie na XML jako u Apache.

XML máš parsovat XML parserem a jestli jsou atributy na stejném řádku nebo na novém tě nemá vůbec zajímat. Nic jako klíče¹ tam není – jsou to uzly, elementy a těch tam z principu může být víc². Pokud to má být nějak omezené, můžeš použít atribut, ten tam bude maximálně jednou nebo takové omezení napiš do XSDčka.

Z praktického hlediska: když budu chtít „vyzobat“ nějaké hodnoty z XML konfiguráku, stačí mi na to jednoduchý XPath dotaz nebo si napíšu jednoduché XSLT, které to převede na něco jiného (třeba XHTML, které si může otevřít i BFU a podívat se, co v tom konfiguráku je a jaký to má význam). Když budu chtít udělat totéž (např. z nějaké sekce vytáhnout určité hodnoty), musím nejdřív nastudovat syntaxi daného „jednoduchého textového formátu“ a pak si vzít na pomoc třeba Perl a napsat v něm program na pár řádků. Neříkám, že to nejde, ale je to méně standardní a pracnější.

_{[1] resp. jedinečným klíčem může být atribut id
[2] např. seznam souborů, seznam oprávněných uživatelů, seznam domén}

[Šangala]

Už vím, že miluješ XML a tedy nejsi objektivní - mimo jiné, uvědomuješ si, že když je to tak udělané, jsou v zásadě spokojené obě skupiny (pro XML i lehce parsovatelné). Pokud někdo považuje XML-ko bez atributů za čitelné a ručně upravitelné, tak to pochopím, ale pokud si to někdo myslí i o XML-ku s atributy, tak je pro mě XML fanatik. Konfiguráky mají být ručně snadno editovatelné a čitelné. XML-ko vzniklo jako universální výměnný formát. Jako nativní formát, se hodí jen na něco, a dle mého, konfiguráky to určitě nejsou.

PS: Ony jsou to klíče (i když ne unikátní), pokud jsou jedinečné, struktura je tam informace navíc, kterou lze použít nebo ne. U spoustu XML dokumentů záleží na pořadí.

OT: A spousta aplikací kolabuje při parsování XML dokumentů, protože načítá DOM (místo čtení založeném na event-ech), nejlepší je když se ještě validuje dokument vůči šabloně a na prkotinu potřebuješ gigabajty paměti. Navíc je XML-ko strašně ukecané a nepomáhá ani komprimace. Přimlouval bych se, používejme jej jen tam kde je třeba, tedy při mezi aplikační výměně dat.

[xkucf03]

ale pokud si to někdo myslí i o XML-ku s atributy, tak je pro mě XML fanatik.

Pořád nechápu, co máš proti těm atributům – proč by mělo být špatně:

<element atribut1="hodnota1" atribut2="hodnota2"/>

a chtěl bys radši:

<element>
    <atribut1>hodnota1</atribut1>
    <atribut2>hodnota2</atribut2>
</element>

Vždyť ti to dá i méně práce napsat ručně atribut než element.

Ony jsou to klíče (i když ne unikátní), pokud jsou jedinečné, struktura je tam informace navíc, kterou lze použít nebo ne.

Že ta cesta od kořene k textovému uzlu tvořená názvy elementů je jedinečná, to je jen vedlejší efekt, může to tak být a nemusí. Kdekoli v té cestě může být nejedinečnost (více stejnojmenných elementů na stejné úrovni) a to je na tom právě to krásné a mocné. Můžu mít např. více virtuálních serverů a v každém mít více adresářů a každý z nich má jiná přístupová práva (např. povolení pro uživatelské skupiny), nebo tam je něco z toho jen jednou.

Vždyť ten XPath je vlastně ten klíč, který potřebuješ – v nejjednodušším případě je to jen cesta tvořená názvy elementů pospojovaná lomítky. Akorát tam můžeš (když potřebuješ) občas připsat hranatou závorku a do ní nějaký filtr na atributy nebo další vlastnosti.

Prostě místo:

aaa.bbb.opice.ccc

napíšeš:

/aaa/bbb[@nazev='opice']/ccc

nebo

/aaa/bbb[1]/ccc

Přičemž to druhé a třetí (XPath) je standardizované a má to jasná obecná pravidla, zatímco to první se bude lišit formát od formátu, někde budeš psát tohle, jinde třeba bbb.1.ccc nebo ještě hůř bbb1.ccc.

U spoustu XML dokumentů záleží na pořadí.

To je bohužel chyba toho, kdo DTD nebo Schéma pro daný formát navrhoval – dá se to udělat i tak, že na pořadí nezáleží (a mělo by se to tak dělat, jinak je to zbytečná buzerace)

[xkucf03]

P.S. nebo zápis více hodnot – viz jeden reálný příklad (raději nebudu jmenovat, ale diskutovali jsme to tu na Ábíčku) resp. odstrašující příklad, kde se v jednom konfiguráku vícenásobné hodnoty zapisovaly jednou jako čárkou oddělené:

nějaký_klíč=hodnota1,hodnota2

a jinde pro změnu:

nějaký_jiný_klíč1=hodnota1
nějaký_jiný_klíč2=hodnota2

V XML prostě vložíš víckrát ten element a nemusíš tam dělat takové prasárny – je to hezké a systematické.

[Šangala]

Není rozdíly mezi:

key=value1
key=value2

a

<key>value1</key>
<key>value2</key>

Nemám nic proti:

key=value1,value2

pokud je to třeba set modulů, je to vlastně normální pole.

[Šangala]

Ano, rozhodně bych chtěl to druhé, když už to má být ukecané, tak ť je to i čitelné a lehce parsovatelné...

Že ta cesta od kořene k textovému uzlu tvořená názvy elementů je jedinečná, to je jen vedlejší efekt, může to tak být a nemusí.

Je bezva, když to není vedlejší efekt, a že to sem tam někdo i dá do specifikace.

Můžu mít např. více virtuálních serverů a v každém mít více adresářů a každý z nich má jiná přístupová práva (např. povolení pro uživatelské skupiny), nebo tam je něco z toho jen jednou.

Toto

[server]
name=server1

[dir]
path=/kuk
perm=777

[server]
name=server2

[dir]
path=/kukoo
perm=555

[dir]
path=/kukuu
perm=444

je úplně to samé co to XML-ko, rozdíl je jen v tom, že toto čteš (od předu do zadu) a xml-ko parsuješ.

Neustále nechceš přijmout to, že s běžným texťákem lze pracovat jakkoliv, kdežtože s XML-kem rozumně jen pomocí XML parseru a že z toho není každý nadšený.

To je bohužel chyba toho, kdo DTD nebo Schéma pro daný formát navrhoval – dá se to udělat i tak, že na pořadí nezáleží (a mělo by se to tak dělat, jinak je to zbytečná buzerace)

To jakože bych se u těch elementů ještě uvedlo pořadí a pak se setřídilo - tak tomu říkám buzerace zas já.

[xkucf03]

Toto…

Tam ti právě chybí informace o struktuře. Jak mám poznat, že [dir] patří pod [server] a není to jen jiná položka na stejné úrovni?

Nějaké náznaky vnořených strukturu jsem v INI souborech občas viděl, ale nevím o tom, že by to bylo nějak standardizované. Něco ve stylu [sekce\podsekce], ale tam je problém právě v tom, že tam chybí ta identita – nevíš do které sekce ta podsekce patří – tzn. je to použitelné jen pro struktury, kde je všechno maximálně jednou.

Případně by se dalo vymyslet něco jako:

[sekce]
a=b
[.podsekce]
c=d
[..podpodsekce]
e=f

Kde by záleželo na pořadí, na kontextu a nějak bys tam vyznačoval úroveň zanoření. Ale to jsou už fakt obskurnosti.

Neustále nechceš přijmout to, že s běžným texťákem lze pracovat jakkoliv

Ano, pro strojové zpracování XML potřebuji parser případně další knihovny, ale vtip je v tom, že tyhle nástroje aspoň existují – u jiných formátů ani neexistují nebo dokonce chybí i formální specifikace formátu – celé je to na vodě, někdo si z hlavy vymyslel „formát“ napsal ukázkový soubor a napsal proceduru/funkci (schovanou kdesi v jeho programu), která tento formát umí načíst a vytvořit v paměti struktury daného jazyka nebo během načítání průběžně volat nějaké jiné funkce, které cosi zkonfigurují.

Příklad: Dejme tomu, že chci znát práva k adresáři /kukoo v serveru server2.

V případě XML napíšu něco jako:

//server[@name='server2']/dir[@path='/kukoo']/@perm

V případě toho textového formátu si asi vezmu na pomoc Perl a v něm budu iterovat přes jednotlivé řádky, vytvořím si pár pomocných proměnných, nějaký ten IF a taky se výsledku nakonec nějak doberu.

Případně použiji nějaký hotový parser INI souborů, ale opět budu muset napsat nějaký ten cyklus a nějaké ty IFy, abych si z toho vytáhl požadovanou hodnotu.

To jakože bych se u těch elementů ještě uvedlo pořadí a pak se setřídilo - tak tomu říkám buzerace zas já.

Nerozumím. Myslel jsem, že se bavíme např. o případu, kdy v elementu komponenta můžu nakonfigurovat věci jako volba1 a volba2. Z podstaty věci na pořadí nezáleží, ale přiložené DTDčko mě nutí uvést nejdřív volbu1 a až pak volbu2 (což já z hlavy nemůžu vědět a pamatuji si jen názvy těch voleb, tudíž je to opruz trefovat to správné pořadí). Formální schéma někdo navrhl špatně, příliš přísně a měl to udělat tak, aby to šlo zapisovat i v jiném pořadí (což udělat lze).

Pokud naopak na pořadí záleží, tak považuji za správné, aby se bralo pořadí, v jakém jsou uvedené elementy v XML dokumentu a nemusely se tam doplňovat např. atributy pořadí="1" atd.

[xkucf03]

BTW: jeden z mých (mnoha) rozpracovaných projektů je nástroj, který bude převádět různé formáty na XML¹ a umožní provádění XPath dotazů nebo XSLT transformací např. nad INI nebo YAML soubory případně dalšími formáty. Takže pokud se někomu hnusí² psaní XML dokumentů, může je psát v něčem jiném, ale přesto bude mít k dispozici ten ekosystém XML nástrojů – XPath, XQuery, XSLT, XSD, Schematron… Tudíž si budeš moci zvalidovat INI soubor proti schématu nebo z něj vytáhnout nějaké hodnoty XPathem.

_{[1] přesněji řečeno SAX události, takže půjde proudově zpracovávat „nekonečné“ soubory
[2] nebo je naopak nucen používat jiný formát, i když by radši dal přednost XML}

[Šangala]

A představ si, že dokonce lze ty [...] i vypustit, pokud budou klíče unikátní. Špatně nad tím přemýšlíš, to že to tam viditelně není neznamená, že to tam není (nebo, že je to třeba :) ).

[Josef Kufner]

INI je na složitější data celkem horor. Jeden čas jsem je používal celkem intenzivně, neboť je to vcelku příjemný formát na psaní konfigurace, ale jakmile dojde na složitější struktury, třeba i jen tenhle příklad s virtuálními servery, je to na prd. Řešit se to dá, ale velmi rychle to ztrácí na eleganci.

Pokud někdo uvažuje o INI pro konfiguraci, radši ať veme rovnou JSON. V praxi se mi to osvědčilo a horší to je jen o spoustu uvozovek. Pokud by se upravil parser JSONu o to, aby klíč nemusel být v uvozovkách a doplnily se komentáře, bylo by to stejně pohodlné, jako INI, jen mnohem lepší. JSON tak, jak je standardizován je fajn při kombinaci textového editoru a automatických nástrojů (grafické klikátko ke konfigurování), nebo k výměně dat mezi programy.

[Václav HFechs Švirga]

Ještě existuje Yaml. I když jasně, je tam zas "nevýhoda" (pro někoho) s tím odsazováním pomocí mezer.

[Josef Kufner]

Na těhle formátech mi vadí složitá syntaxe. Autoři tvrdí, jak to děsně "zjednodušují", ale pak je prd vidět, co to vlastně znamená a jak se co píše. To radši těch pár uvozovek a závorek navíc – sice trochu ukecanější, ale ve výsledku mnohem jednodušší na používání.

[xkucf03]

Pokud by se upravil parser JSONu o to, aby klíč nemusel být v uvozovkách a doplnily se komentáře

Ano, tak už by to nebyl tak na hovno formát a možná by to na tu konfiguraci šlo použít. Jenže už by to nebyl JSON. (trefil jsi přesně dvě věci, které mi na něm vadí nejvíc)

[Josef Kufner]

Ono to je i není nevýhoda. Záleží na způsobu použití. Pro konfigurační soubory (read-only z pohledu programu) to je jasná nevýhoda, ale pro strojově zpracovávaná data (read-write), do kterých uživatel zasahuje ručně jen málo, ale hodí se je mít čitelné i bez programu, je to super, protože absence komentářů značně zjednodušuje jejich rekonstrukci při ukládání upraveného souboru. A v tomhle případě ani nevadí ty zbytečné uvozovky u klíčů.

[xkucf03]

ale pro strojově zpracovávaná data (read-write), do kterých uživatel zasahuje ručně jen málo, ale hodí se je mít čitelné i bez programu, je to super, protože absence komentářů značně zjednodušuje jejich rekonstrukci při ukládání upraveného souboru.

Zajímavé je, že u XML tohle lze – komentář je prostě jen jeden z typů uzlu. Lidsky čitelné i bez programu to taky je. A kdybych potřeboval hodně optimalizovat, tak použiji binární formát (i za cenu toho, že pro prohlížení člověkem bude potřeba nějaký program – třeba Wireshark, ve kterém se různá binární data zkoumají dost pohodlně). Nějak pro ten JSON prostě nemám využití (ale dokážu si představit využití pro INI soubory nebo YAML).

[Josef Kufner]

komentář je prostě jen jeden z typů uzlu.

V tom je právě ta potíž. Takovéhle věci nesktečně komplikují aplikaci, která ty soubory zpracovává. Na JSON stačí v podstatě hash tabulka a seznam, u dostatečně dynamických jazyků je to ještě jednodušší. V podstatě můžeš JSONem přímo krmit objekty a po opětovné serializaci takových objektů do JSONu nepřijdeš o data, např. o komentáře, styly, DTD a podobně.

[xkucf03]

Ale vždyť ten komentář je jen prvek seznamu – a je jiného typu, takže ho při běžném zpracování budeš ignorovat (ale necháš ho tam) a při serializaci se zase normálně zapíše.

Dejme tomu, že máš uzel „konfigurace“ a v něm uzly „virtuálníServer“ a pak třeba uzly „popis“ nebo něco dalšího a pak ještě komentáře. Funkce, která má zkonfigurovat virtuální servery bude iterovat přes ty prvky a pokud je jejich typ virtuální server, tak je zpracuje (nebo se to filtrování udělá nějak jinak). Tohle je dobré i kvůli kompatibilitě – v konfiguráku můžou přibýt nové volby a stará verze programu je bude ignorovat (nebo jen vypíše varování, že něčemu nerozumí).

[JS1]

Uz syntakticky je prece uzitecne oddelit komentar od zbytku, napr. v textovem editoru.

[xkucf03]

Ale jistě, syntakticky to oddělené je <!-- komentář --> vs. <element/>, ale to nebrání v tom, aby parser načetl i ty komentáře a dalo se s nimi nějak dál pracovat, je-li to potřeba – když je ale parser zahodí/přeskočí, tak už to nemůžeš bezztrátově číst/zapisovat, což je pro nějaké aktualizace dost na nic. Tohle se dá aplikovat u programovacího jazyka, kde ty komentáře fakt lze zahodit, ale pokud je to ne-programovací jazyk pro popis dat, tak by mělo být možné ty komentáře zachovat a přitom měnit data.

[xkucf03]

P.S. a po načtení a převodu na nějaké struktury/objekty programovacího jazyka je to zase oddělené na úrovni datových typů (komentář bude jiného typu než text, element, atribut…).

[Šangala]

Nevím jak ostatní, ale případy jako uvedený případ s VS bych teda raději rozdělil na jednotlivé soubory (a adresáře) s normálními konfiguráky, pak je to hezky spravovatelné, oddělené, změny jasně identifikovatelné na minimálním celku a na jednu obrazovku se vleze maximum informací.

Podle mě, na výměnu informací jak XML tak JSON je OK, ale na konfiguráky s ohledem na správu je to často monolitické utrpení. Tyto informace by měli ukládat s ohledem na uživatele a správce, ne s ohledem na to vývojáře. Registry jsou také strukturované řešení totálně na prd...

[xkucf03]

Nevím jak ostatní, ale případy jako uvedený případ s VS bych teda raději rozdělil na jednotlivé soubory (a adresáře) s normálními konfiguráky, pak je to hezky spravovatelné, oddělené, změny jasně identifikovatelné na minimálním celku a na jednu obrazovku se vleze maximum informací.

jj, tohle je taky možnost – použít jako formát souborový systém a popsat tu stromovou strukturu pomocí adresářů a souborů – pokud jich nebudou sta tisíce (u běžné konfigurace snad nehrozí), tak je to v pohodě. Uvnitř těch souborů pak může být prostě struktura klíč=hodnota (akorát je potřeba dohodnout kódování a formát zápisu víceřádkových hodnot, případně nějaké to escapování, pokud by klíč měl být libovolný řetězec a mohl obsahovat znak =). S tím by se pak dalo velmi dobře pracovat a i by se to hezky verzovalo (už ve verzovacím systému bys viděl, v jaké sekci se dělaly změny). Akorát by trochu chyběl ten celkový pohled – všechno na jedné obrazovce – ale na to by se dal napsat celkem jednoduchý nástroj, který by to pospojoval a čitelně naformátoval.

[Šangala]

No.., - je to léty odzkoušená možnost.

Obsah '=' je řešen automaticky, klíč nemůže obsahovat '=' a pak nás zajímá jen první '='.

Víceřádkový text není zrovna častá věc, ale stačí to řešit prázdným řádkem (+ klasický escape netisknutelných znaků).

[Josef Kufner]

Pěknou syntaxi má Apache. XML-like tagy pro sekce a klíč-hodnota pro vlastní konfiguraci uvnitř sekcí. A protože jsou tagy párové, lze je pohodlně vnořovat. V podstatě je to takový lepší INI.

[Bedňa]

OMG, to jsou kecy. Já zase nemůžu z toho, když někdo spatlá miliontý „jednoduchý textový formát“ a já se musím po milionté učit, jak se oddělují klíče a hodnoty, jestli jsou na koncích řádků středníky, jak se píší komentáře, jestli jsou hodnoty v uvozovkách a jak a jestli jsou tam struktury, jestli se používají třeba složené závorky, nebo jednoduché nebo nějaká obskurní parodie na XML jako u Apache.

S týmto som fakt nemal nikdy problém a pri tom nepoužívam klikátka a softvér si nastavujem cez konfiguráky. Dobre napísaný konfigurák má všetku nápovedu v sebe a nepotrebuješ nič hľadať. Zato nepoznám jediný softvér čo používa XML a niesu s ním problémy, našťastie už nič také nepoužívam.

[Josef Kufner]

[...], nebo případně alespoň definovaná vyšší restrikce nad XML, což je velmi výjimečně k vidění (typu, každý klíč je unikátní, odřádkování je vždy po entitě, použíté jsou jen tyto HTML entity a je to vždy utf-8), ale když je někdo -píp- a použije i atributy, tak je to zabité.

Právě jsi popsal JSON

[xkucf03]

Který je pro konfiguráky nepoužitelný (mj. kvůli chybějícím komentářům) a odřádkování neřeší – klidně to může být všechno namaštěné na jednom, takže to stejně negrepneš nebo nezpracuješ v nějakém cyklu po řádcích.

[Václav HFechs Švirga]

YAML?

[xkucf03]

jj, YAML je relativně dobrý (ve srovnání s JSONem určitě)

[Josef Kufner]

No... Když tak porovnám jejich specifikace: YAML vs. JSON. Nemůžu si pomoct, ale YAML je neskutečná kopa hnoje.

[Martin Lojda]

A co takovy Neon? Samozrejme kdyz pomineme, ze je momentalne implementace jen v PHP...

[xkucf03]

Kéž by to mělo nějakou specifikaci a nemělo tak těsnou vazbu na PHP a Nette…

[Josef Kufner]

To je úplně to samé.

[JS1]

Idealni by IMHO byla nejaka forma s-expressions, i u toho JSONu mi prijde, ze ma zbytecne moc zavorek. Mozna by to fakt jen chtelo dotazovaci nastroj.

[xkucf03]

Keď budem chcieť nejaké štruktúry, tak použijem syntax like C.

Existuje nad tím nějaký dotazovací jazyk – něco jako XPath pro XML nebo SQL pro relační databáze?

[Bedňa]

Sranda je, že to vôbec nepotrebuješ.

[Stydlín]

Prosímtě, jakej font máš na těch screenshotech?

[Šangala]

Určitě Terminus.

[Šangala]

Aha, tak ne, sorry, to jsou snímky přes Putty s herní konzole, takže je to Courier New.