nevyhody:
* vetsi rezie pri zpracovani
* hodi se jen pro data jako takova -- asi nenahradi "kofiguraky" typu skript v necem (bash, perl,...)
vyhody:
* jednotny format, s kterym lze pracovat pres ruzne rozhranni - pro cteni muzu pouzit jednoduchy parser, pro editaci DOM (nebo lepe nejakou nadstavbu), ktery mi umozni dobre omezit zmenu na jedno misto(krome toho s trochou snahy by slo i pridelit ruznym sekcim ruzna pristupova prava atd.);
* moznost validace -- vetsina aplikaci nema moznost spusteni v rezimu "validuj svuj konfigurak" a pri spatne konfiguraci spadne nebo znestabilni
* moznost prevodu na jiny format stnadrdizovanymi prostredky -- co z konfigurace vygenerovat treba schema virtualnich webu pro rychly prehled nebo dokonce navigaci ?
* prehlednost
---
Moznost omezit rozsah zasahu k souboru je potrebna
vec. Pokud vam nejaky front-end pro rychle nastaveni cehosi prepise cely konfigurak a vy prijdete o pracne vypiplane detaily, kterym zrovna nerozumi, je to nepouzitelne. DOM by umoznil omezit zmeny na konkretni sekci/elment, a to bez nutnosti znalosti
konfigurace.
Ty vyhody nejsou az zas tak jednoznacny. Priklad: Jmeno="Karel"
<Jmeno>Karel</Jmeno>
<Jmeno Value="Karel"/>
<Jmeno><Value>Karel</Value>...
atd atd. Muzete namitnout, ze to lze definovat v nejaky norme, ale je tu spousta pripadu bez normovani a v ramci jednoho dokumentu to lze michat a pak je v tom peknej bordel, protoze to neni jednotny. A pokud se do toho zacne michat namespace, pak je to peknej gulas. Co se tyka validace, to je silnej argument, ale pokud si nadefinuju bin. strukturu a opatrim ji checksum, coz je trivialni, pak nemusim delat casove narocny validovani. Ta prehlednost je kvaziargument, protoze, pokud s datama dela predevsim pocitac, tak je nutny ty data uzpusobit predevsim pocitaci! A ne ze to dizajnuju s tim, co kdyby muj mene PC gramotny sef chtel videt obsah dat. Takze xml budiz, ale vocad - pocad.
Mate pravdu, byl to jen priklad (a blbej). Mam skusenosti s velkymi i malymi schematy (XDR, XSD) a muzu rict, ze zatimco malo strukturalni soubory lze popsat rychle tak velky a clenity soubory popisovat je dost tezkopadny a zdlouhavy - nehlede na nejkrasnejsi aspekt XSD, ze hlavy z w3c tu definici menej jako spodni pradlo. A vzhledem ke slozitosti implementace konkretne apache xerces a xalan, je vzdy v nove verzi i novy xsd a stary je nepodporovan. Takze kazdejch pul roku menime schemata, coz je opravdu slast. Me osobne se mnohem vice zamlouva nikoliv validace podle dalsiho popisnyho souboru, ale primo programove, protoze pak mate kontrolu nad programem mnohem vetsi, konec koncu pravdepodobne se xml soubor zpracovava obektove a pak je velmi snadne aby kazdy objekt zpracovavajici tu svoji cast si ji taky zkontroloval (coz stejne musi, aby program nepadal na hubu na nicnerikajici hlasky nullpointer a pod)
S tou přehledností si děláte srandu, ne? Doporučoval bych všem nadšencům do XML zkusit si přepsat jednu stránku učebnice matematické analýzy do MathML. Představa, že bych musel své konfiguráky editovat v XML, má pro mě charakter noční můry.
Když už bych toužil po částečné unifikaci zápisu konfiguračních souborů (nápad, že by vše šlo nádherně obhospodařovat nějakým skvělým klikacím nástrojem, patří do kategorie marketingových nesmyslů), což by opravdu nemuselo být špatné, uvažoval bych třeba o Guile. To je mnohem přehlednější, lze to editovat normálně v Emacsu a mohu používat programové konstrukce, což je u komplikovanějších konfiguráků obrovská výhoda.
Zavrhovat XML jen kvůli jedné jeho aplikaci -- MathML -- mi připadá trochu nefér.
Co se týče Guile nebyl bych velký optimista. Jestli se nepletu je Guile založeno na Scheme. Ač mám tento druh jazyků docela rád, jejich širšího nasazení se asi nedočkáme.
Například pro formátování a transformaci SGML/XML dokumentů existuje jazyk DSSSL, který je založen na Scheme. Když jeho rozšíření/oblibu/počet implementacá/... srovnáte s XSL, které umí v podstatě totéž (dokonce o něco méně), dojdete k závěru, že se DSSSL v širším měřítku neprosadilo. Jedním z důvodů bylo například to, že dotazovací jazyk zapisovaný jako výrazy ve Scheme byl nesmírně upovídaný a nepřehledný. Proto byl pro potřeby XSL vytvořen XPath, který má mnohem kompaktnější syntaxi.
A neptejte se mě, proč většině lidí na Scheme/Lisp vadí to množství závorek. To opravdu nevím. Asi ze stejného důvodu, z jakého někomu vadí XML tagy :-D
Na druhou stranu ono psat v MathML je peklo i v (x)html ;). Jak predvedl tusimze Satrapa v jeho skvele knize, kvadraticka rovnice na jednu stranku zamrzi, pri prepoctu jsem zjistil ze ctyrbarevny gif je kratsi nez math zapis...
MathML jsem uváděl jako příklad, ne důvod. Měl jsem tu čest pracovat s DSSSL i XSL a zrovna XSL bylo velmi silným akcelerátorem mé averze vůči způsobu používání XML. DSSSL je záležitost trochu nemotorná (a XML udělátka se z toho jistě trochu poučila), ale dá se v tom aspoň trochu vyznat a rozumně s tím v editoru pracovat. Zápis XPath podle mě nemá s XML celkem nic společného, takže je mimo téma.
Jedna věc je přehlednost, tj. způsob zápisu. Zapíšete-li guilový program v XML syntaxi, vznikne z toho pochopitelně stejné zvěrstvo jako v případě XSL nebo něčeho podobného. Druhá věc je pak možnost používání programových konstrukcí, která je třeba v XSL i DSSSL pro potřeby praktické správy konfiguračních nedostačující. Třetí, již méně důležitou věcí, je snadnost parsování, v čemž XML také nevyniká. XML prostě havaruje na všech těchto požadavcích, přičemž na prvním z nich již ze své podstaty.
