Jak (ne)používat XML

XML je hojně používaný formát pro ukládání a výměnu dat, je často vyzdvihován, ale i kritizován. V následujícím textu se podíváme na příklad špatného použití XML a pokusíme se navrhnout správné řešení.

Jako příklad jsem vybral jeden systém, který do XML ukládá svoji konfiguraci – konkrétní název uvádět nebudu – na něm totiž nesejde, podobných případů najdeme bohužel mnoho. Zde je zkrácený a upravený příklad:

<?xml version="1.0" encoding="UTF-8"?>
<xlist version="0.9">
    <dict>        
        <key>ApplicationXYZ</key>
        <dict>
            <key>DatabaseURL</key>
            <string>postgresql://localhost/xyz</string>
            <key>MailingMechanism</key>
            <string>smtp</string>        
            <key>SMTPServer</key>
            <string>localhost</string>
            <key>UserSources</key>
            <array>
                <dict>
                    <key>canAuthenticate</key>
                    <string>YES</string>
                    <key>id</key>
                    <string>directory</string>
                    <key>isAddressBook</key>
                    <string>YES</string>                
                    <key>passwordHashAlgorithm</key>
                    <string>md5</string>
                    <key>DatabaseURL</key>
                    <string>postgresql://localhost/xyz/users</string>
                </dict>
            </array>
        </dict>
    </dict>
</xlist>

Tento soubor slouží k ukládání konfigurace různých aplikací, umožňuje zachytit stromovou strukturu (viz <dict/> a <array/>) konfiguračních položek, ale i prosté dvojice klíč-hodnota (viz <key/> a <string/>). Tímto způsobem můžeme ukládat předem neznámé datové struktury – což je potřeba, protože dopředu neznáme požadavky jednotlivých aplikací. Je tento formát XML ale v pořádku?

Syntaxe a sémantika

Výše uvedený soubor má nějakou svoji syntaxi a sémantiku. Syntaxe má vlastně dvě, ale o tom až později.

Syntaxe – jak můžeme vypozorovat, dokument obsahuje přiřazení klíč-hodnota – po elementu <key/> vždy následuje element <string/>, ve kterém je uložena hodnota. Nebo, v případě složené hodnoty, místo <string/> následuje <dict/> obsahující vnořenou strukturu nebo element <array/> obsahující pole hodnot (případně vnořených struktur). Tuto syntaxi můžeme definovat pomocí některého jazyka pro schémata (např. XML Schema, Schematron, Relax NG atd.). Pomocí schématu definujeme, které elementy má dokument obsahovat, jak mají jít za sebou, kolikrát se mohou vyskytovat a další pravidla.

<key>klíč 1</key>
<string>hodnota 1</string>

Sémantika – sémantika je obecně nauka o významu jednotlivých slov a znaků. V našem případě se týká významu jednotlivých klíčů a jejich hodnot. Jaký význam má např. DatabaseURL? A proč nemůžeme napsat database_url? Nebo můžeme? Bude tomu aplikace rozumět? Jaký význam přisoudí takovému klíči, pokud ho v konfiguračním souboru najde? Sémantiku nikde definovanou nemáme – ono to ani nejde, protože náš formát je příliš obecný a je určen pro všechny možné aplikace – významu těch dat tedy rozumí jen daná aplikace.

Jak to udělat správně

Když se nad daným souborem zamyslíme, uvědomíme si i tu druhou úroveň syntaxe. Vždyť už XML samo o sobě má syntaxi – říká nám, jak psát <značky/> do ostrých závorek, že elementy můžeme vnořovat do sebe, že mohou obsahovat atributy, že se značky nesmí křížit, říká nám, jak máme escapovat speciální znaky atd. Vždyť už XML samotné je přiřazením <klíč>hodnota</klíč> (včetně složitějších vnořených struktur).

Formát XML nám nabízí vše, co potřebujeme – není důvod nad ním vytvářet ještě jednu syntaxi!

Konfigurační soubor by klidně mohl vypadat takhle:

<?xml version="1.0" encoding="UTF-8"?>
<xlist version="0.9">
    <application id="ApplicationXYZ">
        <DatabaseURL>postgresql://localhost/xyz</DatabaseURL>
        <MailingMechanism>smtp</MailingMechanism>
        <SMTPServer>localhost</SMTPServer>
        <UserSources>
            <UserSource>
                <canAuthenticate>YES</canAuthenticate>
                <id>directory</id>
                <isAddressBook>YES</isAddressBook>
                <passwordHashAlgorithm>md5</passwordHashAlgorithm>
                <DatabaseURL>postgresql://localhost/xyz/users</DatabaseURL>
            </UserSource>
        </UserSources>
    </application>
</xlist>

Místo nesmyslného:

<key>DatabaseURL</key>
<string>postgresql://localhost/xyz</string>

jednoduše zapíšeme:

<DatabaseURL>postgresql://localhost/xyz</DatabaseURL>

Místo abychom klíč a hodnotu uváděli jako obsah elementů, uděláme element přímo z klíče a uvnitř něj bude (jako textový obsah) hodnota.

XML bez schématu není hřích

Někdy (jako např. v tomto případě) potřebujeme formát, který umožní zachytit předem neznámá a všelijak strukturovaná data. Potřebujeme volnější formát, který pojme ledasco, a aplikace už si to přebere. V takovém případě není nic špatného na použití XML bez schématu nebo XML s velmi volným schématem – v našem případě bychom definovali jen kořenový element, který obsahuje neurčitý počet elementů <application/>. Obsah těchto elementů bychom už nijak schématem neomezovali – stejně jako autoři původního formátu neomezovali obsah elementů <key/> a <string/>. Neomezovali ho proto, protože nemohli vědět, co si do nich aplikace bude chtít uložit.

Pokud tedy potřebujete uložit nějaké volné a předem neznámé datové struktury, použijte klidně XML bez schématu – není to hřích, XML schéma mít nemusí. Tím schématem byste totiž nezvýšili spolehlivost aplikace a nesnížili riziko chyby – takové schéma by totiž stejně nepostihovalo sémantiku (zda tam uživatel napíše DatabaseURL nebo database_url, kterému aplikace nebude rozumět). Není potřeba vynalézat kolo a vytvářet ještě jednu úroveň syntaxe, které nic nepřináší – XML samo o sobě nám dá vše, co v tomto případě potřebujeme: uložení stromových struktur a přiřazení klíč-hodnota.

Závěr

Prvotní rozhodnutí (použít XML pro uložení dat nebo komunikaci) je většinou správné. V čem se ale často chybuje a co si zaslouží kritiku je následná tvorba formátu. Až přístě uslyšíte kritiku XML (nebo budete sami kritizovat), zkuste se zamyslet, jestli je to (1) kritika špatného formátu postaveného na XML (2) kritika použití XML tam, kde to není vhodné (3) kritika XML formátu jako takového.

P.S. poznali jste, z které aplikace/systému příklad pochází? :-)