Názory k článku Příliš obtížné XML?

Me tedy prijde, ze se s XML udelal vselek. XML je IMHO dokonale treba pro vymenu dokumentu. Komunikaci treba mezi ucetnim programem a webovym obchodem. Ale nacpat to vsude ? Treba nove GNOME a KDE maji tusim konfiguraky v XML. No nazdar to bude zase line rozezrane na pamet.

To je nesmysl, v XML ma konfigurak treba gentoo (fm), docela rozsahlej a startuje prakticky okamzite. Ja si myslim, ze by naopak vsichni meli prechazet a konfiguraky v XML, aby konfigurace celeho linuxu byla jednotna. Vzdyt je to hanba, kazdej pes jina ves. Vsechny cfg. nastroje by mely mit jednotne api a ne ze na deset programu musim mit deset ruznych parseru.

Konfigurak v XML bude skvely, az na to budu mit slusne editacni nastroje. (Mozna uz existuji)

To by pak Linux mohl mit jeden velky konfigurak v XML. Takove (znacne vylepsene) registry z windows.
:-)

Tomas T.

Takovej konfigurak by byl taky pekne pomalej. Skus si neco najit ve win registru a uvidis ten fofr jak to jede jako s hnojem protoze to je rozsahla (binarni) stromova struktura a co teprve, kdyz to bude textova, zabirajici 3x tolik co v binaru a parsovani je cca 20x pomalejsi nehlede na to, ze binar muzes projit do urcityho uzlu aniz parsujes data, coz u xml nejde.

Nu pokud to nekdo prochazi pokazda jako textovy file tak to pomale bude, nicmene neni problem si k tomu udelat indexy, hashe ci cokoliv obdobneho a razem je to rychle az az....

Konfigurak v XML bude skvely, az na to budu mit slusne editacni nastroje. (Mozna uz existuji)

To by pak Linux mohl mit jeden velky konfigurak v XML. Takove (znacne vylepsene) registry z windows.
:-)

Tomas T.

1. uklidit /etc by chtelo, konkretne v Mandrake, proto pouzivam Gentoo a nestezuju si.

2. Jeste pred mesicem (!!!) jsem byl take tvrdym zastancem unifikace konfiguraku, nejlepe do xml.

3. Pak jsem si ale uvedomil, ze nektere konfiguraky jsou vlastne programovacimi jazyky, a to dost slozitymi. Nevim, zda by bylo mozne udelat takovy univerzalni XML editor, v nemz by se daly tyto konfiguraky psat stejne jednoduse.

4. Je treba si uvedomit nasledujici: Jde o rozpor Linux vs Windows. Jestli ma byt Linux i nadale jednoduse konfigurovatelny pomoci textovych souboru (a ono to kupodivu jde), nebo prejit do ogromnoje grafickych udelatek a la Mandrake, pro nez by samozrejme bylo nacitani XML konfiguraku lepsi.

5. Vazne nevim, jestli je snaha portovat windowsovskou filozofii na linux dobra (MDK, Lindows). Mozna pro do zacatku, pro snazsi prechod, jenze Linux je system uplne odlisny, s odlisnou filozofii. Aby se z nej nestal molochoidni txt-xml-sql-multi-wine-hybrid.

Moje řeč. Až na to, že myšlenku převodu všecho na XML jsem zavrhl už poměrně dávno ;-)

Pokročilé konfigurování v Unixu (jednoduchým se nemá cenu zabývat, to se nakliká v nějakém wizzardu :-) je v podstatě vždycky skriptování -- definují se proměnné, makra, funkce, a pak se používají, větví se, případně i cyklí, ... kdejaký konfigurační jazyk má sílu Turingova stroje. Filosofie je fakt jiná než na Win a nemyslím si, že špatná.

Zastánce převodu konfiguráků do XML prosím, ať s tím převáděním začnou u mého .bashrc a .bash_profile a pokračují konfiguráky Vimu a Fvwm2, až to zvládnou, rád bych převedl ještě pár drobností jako konfiguraci Apache, včetně mod_rewrite, ale to už bude hračka :o)

Tou Windowsovskou filozofii v MDK (zvlaste ve spojeni s konfiguracnimi soubory) je mysleno jako co?

Napr. MacOS X ma konfiguracni soubory (properties) umistene v xml a soucasti utilit systemu je tzv. Properties Editor, ktery umi pohodlne editovat tyto soubory, a to vsechny, protoze jsou predepsany jednotnym DTD. Je to imho hodne efektivni, coz asi plyne z toho, ze je to inhousove reseni applu. Skoro bych si i tipnul, ze to pouziva jednoduchy, pro ten ucel napsany a tedy rychly "pull parser". Podobny system v linuxu by byl podle super. Staci se jen podivat, jak srozumitelne je rizeni prekladu pomoci antu, nemuzu se dockat, az si stahnu cc tasklet.

A konfigurak uz nie je dokument? ;). Co este je, a co este nie je dokument? :)

Filosoficky vzato jedina vyhoda XML proti beznym konfigurakum je, ze se v XML snadno drzi "stromova" informace. Pak se daji celkem prehledne konstruovat mamuti stromy s konfiguraci (viz XML verze registru windows - vsadil bych se, ze v dalsi verzi win to tak bude :). Timto resenim nicmene ztracime snadnou moznost rychleho rucniho zasahu (napr. vzdalene, pokud je system v havarijnim stavu a vsechny konzolove inteligentni editory (a X-win) nejdou nastartovat :-))) V danem pripade (konfigurace linuxu) mi pripada vuhodnejsi drzet onu stromovou prehlednost na filesystemu pomoci adresaru a vnich mit pekne srovnane konfiguraky v textovych souborech s linearni strukturou.

A neporadek v XML se da udelat stejne snadno jako v /etc v tech textovych souborech.

Jan Koutnik

Jako všechno ostatní ma XML své klady i zápory. Já si myslím, že pokud se dokument drží určitého DTD a nepoužívá se "obecný" parser jde s tím pracovat naprosto dobře. Napsal jsem několik parserů a na rychlost si nestěžuji. Pokud ovšem XML začnu používat zcela obecně dostanu se do problematiky teorie grafů se všemi problémy průchodu obecným grafem a z toho začnou plynout ty problémy...

Na streamove parsovani textu s pravidelnou syntaxi je yacc/bison (pro C), ten se da snadno pouzit i na XML. No a kdyz mam slozite XML ze ktereho jen vyzobavam, tak na to jsou nejlepsi regularni vyrazy v rucne psanem kodu, jako v clanku od Tima Braye. Kdyz z techhle dvou pristupu zkusim udelat hybrid, tak to myslim nedopadne dobre.

Regulární výrazy pro čtení XML nejde obecně použít. Jakmile jsou v dokumentu např. CDATA sekce, komentáře, odkazy na entity apod. přestanou vám fungovat.

Pokud chcete jen něco vyzobávat jsou na to dost dobře použitelné pull-parsery, o kterých Petr psal. Dlouhou dobu byla jedna z mála rozšířených implementací jen XmlReader v .NETu, ale poslední verze libxml2 toto rozhraní převzaly. Takže se skutečně blýská na lepší časy.

Regulární výrazy bych na čtení XML opravdu nikomu nedoporučoval. Je to málo robustní řešení.

Regulární výrazy pro čtení XML nejde obecně použít. Jakmile jsou v dokumentu např. CDATA sekce, komentáře, odkazy na entity apod. přestanou vám fungovat.

Pokud chcete jen něco vyzobávat jsou na to dost dobře použitelné pull-parsery, o kterých Petr psal. Dlouhou dobu byla jedna z mála rozšířených implementací jen XmlReader v .NETu, ale poslední verze libxml2 toto rozhraní převzaly. Takže se skutečně blýská na lepší časy.

Regulární výrazy bych na čtení XML opravdu nikomu nedoporučoval. Je to málo robustní řešení.

Regulární výrazy pro čtení XML nejde obecně použít. Jakmile jsou v dokumentu např. CDATA sekce, komentáře, odkazy na entity apod. přestanou vám fungovat.

Pokud chcete jen něco vyzobávat jsou na to dost dobře použitelné pull-parsery, o kterých Petr psal. Dlouhou dobu byla jedna z mála rozšířených implementací jen XmlReader v .NETu, ale poslední verze libxml2 toto rozhraní převzaly. Takže se skutečně blýská na lepší časy.

Regulární výrazy bych na čtení XML opravdu nikomu nedoporučoval. Je to málo robustní řešení.

Myslim ze ted uz si to budou vsichni pamatovat :-)

T.

P. S. Nestalo by za to udelat jednoduche rozsireni redakcniho systemu, ktere by zamezilo opakovanemu vkladani prispevku?

Třikrát se to do odeslalo opravdu omylem, trošku mi sklouzl prst na touchpadu a už to bylo. Nakonce jsem ani nepsal 4. zbytečný příspěvek s omluvou. Řekl jsem si, že si alespoň všichni budou opravdu pamatovat, že na XML se nemá chodit s regulárními výrazy :-)

Ja len doplnim pre zaujimavost odkaz na http://xmlsucks.org/but_you_have_to_use_it_anyway/ konkretne zaujimave nazory su na http://xmlsucks.org/but_you_have_to_use_it_anyway/does-xml-suck.pdf

Me se libi muj c++ parser, ktery jeste neni uplne hotovy ale funguje takto:

data = xml.get_data("firma[0]/pracovnik[12]/email[23]/subj");

pro zjisteni poctu pracovniku v prvni firme:

int count = xml.get_count("pracovnik", "firma[0]");

a tudiz na parsovani lze pouzit normalni for() a while ().

Dulezite je upozornit ze parser si udrzuje informace o predchozim cteni, a po naslednem pozadavku napr:
xml.get_data("firma[0]/pracovnik[13]...
parser bude uz vedet kde je pracovnik 12 a bude hledat dalsiho pracovnika az odtud (jinak by to bylo hodne pomale v pripade velkych dokumentu).

V jednoduchosti je krasa, rychlost a efektivita :-)

http://www.reportlab.com/xml/pyrxp.html

Myslim, ze zakladnim problemem je chapat XML jako metodu na ulozeni dat. To je pochopitelne pri vetsich objemech naprosto neefektivni a desitky let existuji vyrazne lepsi zpusoby (treba ruzne DB). XML ale muze byt perfektnim zpusobem pro komunikaci, popis a vkladani dat do ruznych systemu a vnitrne muze tento system mit organizova data naprosto jinak a efektivneji. Umim si predstavit Linuxove "XML registry" s konfiguraci systemu kde XML bude jen na disku, ale vnitrne si bude nejaky konfiguracni server udrzovat data v nejakem pro nej efektivnejsim formatu a pouzivat jine vnitrni na praci s daty efektivnejsi API nez DOM/SAX ...

Já si teda svoje konfiguráky bashe, procmailu, Vimu nebo Fvwm2 v XML představit neumím. Leda jako jednolitý CDATA ;-)

Jedna věc jsou přímočaré konfiguráky typických GUI aplikací. To asi není tak velký problém převést do XML -- ostatně ,,Linuxové registry`` už existují, v Gnome to zařizuje GConf a v KDE se to taky nějak jmenuje. Pojem konfigurák je ale v Unixu podstatně širší a víceméně splývá s pojmem program.

Myslim si, ze nemate uplne pravdu. Proc by nemelo XML slouzit k ulozeni velkeho mnozstvi dat? XML muzeme chapat jako nove (tedy jiz 5 let stare) paradigma pro modelovani dat, ktery diky stromove strukture nabizi vetsi moznosti nez relacni ci objektove-relacni databazovy model. Je to vsechno zalezitost casu, kdy se podari najit vhodne datove struktury pro ulozeni velkych XML dokumentu. Podivejte se jak dlouho trvalo vypilovani RSRBD do dnesni podoby.

Na teto diskusi je patrne v cem tkvi sila XML. Pokud ho vnimame jako paradigma, ktere modeluje strukturu dat jako strom, pak muze slouzit jako ulozeni ruznych konfiguraci (obecne dat), prenaseni dat a po zapojeni ruznych indexovacich technik i pro ulozeni velkych kolekci dat. Spousta takovych veci existuje, ale jak zaznelo jiz v clanku a diskusi, XML je na zacatku a da se ocekavat jeste bourlivy vyvoj (dotazovaci jazyky, indexovani, atd.), prechod od DTD k XML Schema je toho dukazem.

Prave velky objem dat je slabina xml. Bud se to musi parsovat cely najednou, takze se obludne szira pamet, nebo parsovat streamove (SAX) a pak je to zase co dotaz, to parsovani, takze to jede jako lemra. To ze bylo xml urceno primarne pro vymeny webovych dat mi s odstupem prijde jako pekna hovadina, protoze xml sezere mnohem vetsi pasmo na prenos nez binar a taktez parsovani je mnohem pomalejsi nez binar, tudiz 2 zasady pro web - rychla odezva a malej tok je v cudu. A neznam pocitac (mozna ze existuje :), kterej dokaze lip parsovat textovy data nez binarni. Xml lze celkem uspesne pouzit na mistech jako je jednoduchej konfiguracni soubor, kterej cas od casu musi prohlidnout clovek, v jinych pripadech je pouziti textovyho tagovyho zaznamu dat znacne neefektivni.

Tech moznosti je samozrejme vice. Proc si myslite ze neni mozne vytvorit index nad XML dokumentem (dokumenty), aby bylo v XML dokumentu mozne efektivne vyhledavat? Relacni tabulku si taky umim predstavit jako textovy soubor, ale byl vymyslen B-strom, ktery nam umozni efektivny vyhledavani v relacnich databazich a nikdo o tom takto neuvazuje. Problem indexovani XML je stale otevreny, za vsechny bych jmenoval alespon reseni XPath Accelerator od Torstena Grusta.

Stejne je to s velikosti souboru. Znovu rikam, ze XML je nutne chapat jako paradigma modelujici strukturu dokumentu jako strom. Existuji komprese XML dokumentu jako je napr. xmi. Vysledkem je kompaktni binarni soubor obsahujici XML dokument.

Index nad xml samozrejme pouzit jde (a b-tree lze snadno implementovat v xml podobe) ale zase to ma nevyhody xml, coz je velikost souboru a rychlost zpracovani. Pravda, mohu pouzit binarni b-tree, ale pak, kdeze je textovy xml ze...
S tou kompresi mate pravdu, nicmene tim opet ziskam binarni soubor a to uz radeji pouziju primy binarni soubor nez toto. Zkousel jsem i pouziti bin-xml v implementaci oracle-java a svete div se, velikost souboru o 30% menzi a rychlost zpracovani 2x mensi.
Kazdopadne stojim si za tim, ze pokud data jsou urcena primarne pro pocitacove zpracovani, maji byt taktez uspusobeny pocitaci a nikoliv human-readable. Pokud se ovsem pocita s lidskym pristupem do techto souboru, pak neni co resit. Myslim ze databazovy servery si firmy nikdy nedovolej prevezt na xml (nemyslim tim podporu xml pro vymenu dat ale primo format db v xml), protoze by okamzite dostali na frak od konkurence z hlediska vykonu a velikosti.

Jak to myslíte, že XML můžeme chápat jako nové paradigma pro modelování dat? Stromové struktury i onen způsob značkování už tu máme pěknou řádku desetiletí. Snad jen ten nápad je zkombinovat pro obecnou externí reprezentaci dat je nového ražení, a hlavně skutečnost, že někdo takový nápad vůbec vzal vážně...

Samozrejme, ale obsahem mych prispevku do diskuse prece nebyla tvrzeni o novosti takovych pristupu. Nyni se "pouze" podarilo vydat specifikaci takove veci (kterou nazyvame XML) a dalsich podpurnych nastroju (popis struktury, dotazovaci jazyky, ...).

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.

Ale validace XML je prece neco principielne jineho nez checksum, tezko to takhle primocare porovnavat.

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.

Udelat konfiguraci v XML je nerealne. staci se podivat co za zverstva se nachazi v /etc (od cfg typu paramert=hodnota az po 400radkove scripty)

mnohem efektivnejsi by bylo dohodnout se na standardnim formatu configu. XML je pouzitelne tak na nastaveni parametru nejake malinke aplikace(tak malinka nebude protoze musi umet rozlustit XML:), ale nedovedu si v nem predstavit configy takove jake je mame pod linuxem dneska

jinak uklidit /etc by jedine prospelo, kazda aplikace si tam placne svoje configy, ale tak jak ji napadne

To jo. A taky ten bordel v /home/*/ je dost hroznej. Jediny stesti, ze neni normalne videt...

Proc proste neni adresar /home/*/.config/ pro lokalni nastaveni _vsech_ programu? (Ze by se nikdo kdysi nedohod?)

Trochu odbocim do sveta Wokenic, pry novej Office 2003 bude celej zaloznej na XML a i word to pry bude ukladat do XML, sem teda zvedavej :-00

jo, ma to jednu musku. Zkus si v wordu vygenerovat html a podivej se do nej. Totalni nic (nadpis + odstavec) zabira bezne 800 kilo a je to jeden brutalni css bastl. Ted si predstav ze krome css bastlu bude jeste jedno multi-mega-hyper-ultra(rozumime si?) DTD... no a pak uz to mozna nikdy nenactes.

Osobně si myslím, že XML svoje skutečné místo ještě hledá. Bohužel je tu z mnoha míst obrovský tlak na to, aby se uvedlo, že XML je skvělé a basta.

XML má svůj účel, ale opravdu si jej jako univerzální konfigurák představit nedokážu. Jednak pro sl

Podle mého hodně rozvoji XML brání to, že je stanovena pouze textová verze. Myslím si, že by nebylo od věci stanovit jednoznačné zobrazení textové verze XML do binární verze. Pak by mohl odpadnout třeba náročný parsing.

Moje rec. Taky jsem si myslel, ze bin-xml by mohlo vyrazne zlehcit parsing, jenze ono ouha. Posledni dobou mam pocit ze se autori tehlech norem se predhanej, kdo vytvori nejslozitejsi a nejmene prehledny format. Podivejte se treba na http://www.w3.org/TR/wbxml/ coz je specifikace wap bin xml a takovej humus jsem uz dlouho nevidel. Uz jsem to tu rikal, ale parsing bin-xml v implementaci oracle v jave trval 2x dele nez parsing textoveho xml...to uz o necem svedci. Pro zajemce stromovych struktur mohu doporucit jazyk ASN.1 a jeho binarni podobu BER/DER. V tomhle binaru se vyskytujou digitalni podpisy, klice a veci s tim souvisejici.

Myslím, že redukovat diskusi o XML na to, zda je dobré v něm psát konfiguráky, je až komická trivializace. Uvedu příklad, kdy jsem XML ve spojení s XSLT opravdu ocenil. Potřeboval jsem v C napsat API, které by pracovalo (tj. parsovalo nebo generovalo) s několika desítkami různých a navzájem dost nepodobných hierarchicky organizovaných datových zpráv (jež nebyly ve formátu XML a byly pevně stanoveny jinou externí aplikací - jeden komunikační systém v EU), umělo je ukládat/číst do/z SQL databáze a předávat programům dalších aplikací ve 4GL Informix. Psát kód ručně znamenalo zohlednit všechny datové struktury zpráv v C, v *.h include souborech, ve 4GL Informix a v SQL schematu databáze a při jejich změně opravovat kód na x místech. Vyřešil jsem to tak, že jsem vlastnosti všech datových zpráv popsal v jednom XML souboru a příslušné knihovny v C, , *.h soubory, kód ve 4GL Informix a SQL schemata generoval pomocí transformačních style-sheetů XSLT s použitím programu XALAN. Po počátečním boji s XSLT se postup ukázal jako nesmírně efektivní - datové zprávy byly popsány jediným XML souborem o asi 1400 řádcích a příslušné style-sheety měly každý max. asi 300 řádek - z toho většina je template kód v C, 4GL, resp. SQL. Pomocí tohoto aparátu mohu kdykoliv za pár vteřin vygenerovat několik desítek tisíc řádek v C, 4GL a SQL s jistotou, že vše, i při změně či přidání další datové zprávy (tj. změně pouze v definičním XML souboru), pasuje dohromady. Od té doby pokládám XML a nástroje s ním spojené za skutečně mocný prostředek.