Migrace na nový způsob zápisu má několik důvodů a výhod. Za prvé je třeba si uvědomit, že vlastní formát DTD není úplně čistým XML - zápis se vymyká standardní struktuře ostatních XML dokumentů, což není žádoucí. Naopak takové schéma je samo o sobě dokument tímto standardem popsaný. Zdá se to trochu zvláštní, dostáváme se ke klasické kruhové definice "Abychom mohli definovat rekurzi, musíme definovat rekurzi. Abychom mohli definovat...". Ale na druhé straně uvažte jen přínos programátorům při práci se schématem. Není potřeba psát cokoliv nového, XML procesor už máme a jelikož schéma je XML, je o starost méně.

Dále, DTD nedisponovalo takovými možnostmi popisu typů atributů a elementů. Vzpomeňte si na ukázkový soubor z minulého dílu, kde byly jednotlivé atributy popsány velmi stroze, ačkoliv šlo evidentně o hodnoty naprosto odlišných struktur. Standard, který popisuje XML schémata definuje taktéž dlouhou řadu všech možných typů a podtypů, které může programátor používat. Jenom popis těch číselných by vydal na samostatný odstavec, neboť celé věc je skutečně dotažená do dokonalosti : čísla kladná, záporná, celá, reálná, velký počet míst... Dále je k použití velká škála formátů data a času, řetězců apod. Programátor si může navíc vytvářet typy vlastní, pomocí odvozování od typů stávajících a/nebo pomocí vzorů.

Do třetice všeho dobrého nesmím opomenout podstatnou principielní změnu v chápání závislosti elementů. Z DTD jsme zvyklí, že elementy stejného jména představují stejný objekt a jakožto dětské elementy jsou jednoznačné. Nyní tomu tak není - určitě se shodneme, že například titul knihy a titul před jménem jsou dvě s sebou nesouvisející věci. Tuto skutečnost lze schématem věrohodně postihnout, aniž by bylo třeba rozlišovat elementy v názvu.

Zbývá dodat, že do češtiny přeložená nebo česky psaná literatura v tomto ohledu mírně zaostává - v současné době se touto formou vydala všehovšudy jedna publikace (Elizabeth Castro, XML pro WWW, SoftPress 2001, Brno). Na druhou stranu ve vývojových nástrojích se do budoucna prakticky s ničím jiným nepočítá a na internetu jsou k dispozici i jednoúčelové nástroje pro práci s XML schématy (typicky programy pro převod z DTD).

Při používání více DTD a/nebo schémat se může lehce stát, že názvy některých atributů či elementů budou kolidovat a tím se jejich vzájemné použití bude vylučovat - parser by měl v celé situaci zmatek. Proto přišli vývojáři s metodou tzv. jmenných prostorů (XML NameSpace).

Každý element je implicitně v kontextu nějaké XML aplikace - tj. týká se nějakého tématu. Než tuto aplikaci (DTD, schéma) začněme v našem datovém souboru používat, je vhodné jí přiřadit nějaký jmenný prostor, ve kterém budou názvy elementů a atributů unikátní. Jednoznačnosti v celém dokumentu pak dosáhneme jednoduše spojením prostru a názvu.

Představme si například XML dokument, který pracuje stromy a s platidly. Abychom rozlišili elementy koruna v kontextu stromu a v kontextu peněz, musíme použít jmenné prostory.

<STROM xmlns:stromy="http://www.les.cz/2002/les"/>

Tím jsme prostor stromy definovali a nyní je možné jeho obsah používat. Zapisujeme v tomto případě obrácenou dvojtečkovou notací : zatímco v definování atribut xmlns:a znamená definování prostoru "a", v něm obsažený element "b" se zapisuje jako a:b (tedy element "b" v jmenném prostoru "a"). Popis koruny stromu bude vypadat následovně:

<stromy:KORUNA stromy:POCET_VETVI="hodně"/>

Tím je náš problém vyřešen.

Samotná data ovšem nemají velký smysl, pokud nemáme v ruce nástroj, který nám umožní jejich adresování. K čemu by nám například bylo tisíce souborů na různých internetových serverech po celém světě, kdyby neexistoval nástroj jednoznačně popisující jejich uložení. Tedy kdyby nebylo schéma URI (Uniform Resource Identifier), resp. URL (Locator) adresy. Ten teprve dává možnost odvolat se na nějaký obsah (tj. bez nutnosti jej kopírovat) krátkým, ale výstižným identifikátorem.

Základní syntaxe standardní URL adresy je dobře známá. Skládá se z použitého protokolu, počítače (+ portu), cesty a zdroje, tj. souboru. Že se dále v HTTP GET hlavičce dají posílat jednotlivé proměnné a jejich hodnoty je věc jiná (slouží k předání informací zpracujícím skriptům), datový zdroj je jednoznačně identifikován i bez nich.

Stejně jako v tomto schématu, který adresuje data na úrovni souborů (či alespoň navenek na úrovni souborového systému), používá většina podobných "jazyků" absolutní a relativní adresování. V prvém případě jde o přesnou specifikaci "místa", kde se data nachází, v druhém se jedná pouze o zapsání vztahu mezi aktuálním a cílovým dokumentem. Zcela výstižně vysvětí celou situaci případ určení domu poštovní adresou (absolutní adresování) a slovním popisem "dům o dva bloky vedle naproti" (relativní adresování - vztahuje se k aktuální budově).

Jelikož ale používáme pro práci s daty jazyk definovaný pomocí XML, potřebujeme něco jemnějšího. Bylo by vhodné najít nástroj, který dokáže jednoznačně ukázat na jednotlivé významové části dokumentu - na elementy.

Adresování jednotlivých datových složek je mimochodem známé i z HTML, určitě si vzpomenete na dvojkřížek (#), který se často objevuje v internetové adrese. V HTML lze totiž definovat název některé "kotvy" (anchor, <A name="jméno">) a při načtení souboru s tzv. identifikátorem fragmentu "jméno" (soubor.html#jméno) prohlížeč automaticky odroluje na část v kódu takto označenou.

Standard XPath tuto potřebu řeší komplexně a nabízí mechanizmus, pomocí něhož můžete nahlížet do dokumentu skutečně ze všech stran. Můžete přesně vybrat jeden element a to jak absolutně (tj. v kontextu celého souboru), tak relativně (tj. "od" současného elementu). Můžete vybrat jakékoliv množství elementů, jak třeba všechny (různé) dětské elementy elementu jiného, tak všechny (stejné) bez ohledu na "hloubku" jejich položení. Do XPath dotazů můžete navíc vkládat spousty dalších aktivních informací. Za zmínku stojí určitě klasické wildcardy neboli žolíky (*), tj. zástupné symboly pro blíže nespecifikované řetězce, podmínky požadující určité hodnoty atributů nebo elementů, práce s klasickými booleovskými výrazy a další. K dispozici jsou také klasické funkce pro práci s řetězci jak například vyhledávání podřetězců, konverze up/downcase, záměna, znak na n-tém místě, délka řetězce apod.

Pokud se vám zdá, že XPath má blízko k SQL, máte pravdu, v principu jde o nástroj, který byl vyvinutý pro stejný účel - odkazování a vyhledávání dat. Tam, kde musíte použít velké množství JOINů zleva zprava, stojí možná za to podívat se na celou situaci z pohledu XML a popřemýšlet nad možností jednoduchého filtru na bázi XPath.

O užitečnosti oddělení informací od vzhledu asi nikdo nepochybuje a právě proto obliba datových formátů popsaných pomocí XML roste. Jednou z hlavních aktivit konsorcia W3C v této oblasti je práce na standardu XHTML - aktuálně ve verzi 2.0 (vydáno v polovině října).

Každý webový programátor, který má alespoň minimální zkušenosti s tvorbou WWW stránek jistě zaznamenal "chaos", který obklopuje klasické HTML. Abych to upřesnil. Funkčních HTML tagů je podstatně více než je potřeba, kvůli kompatibilitě je zachovávána podpora skutečně archaických konstrukcí, jednotlivé browsery si do používaných programovacích jazyků přidávají svoje "vylepšení" a ty syntaxe, ve kterých panuje relativní shoda, si zase často různě vykládají.

Sjednocení hypertextového značkovacího jazyka do standardizované formy si klade za cíl právě XHTML. A proč to X na začátku? Jak asi tušíte, vše je popsáno pomocí XML.

On to sám o sobě není vůbec špatný nápad - nehledě na fakt, že původní verze HTML vycházely ještě z definic postavených na SGML (tento "rodič" XML bude asi pro běžné použití svým potomkem převálcován, neboť práce s ním je pro programátory podstatně těžší a málokde je skutečně do detailů implementován). Jenže postupem času se od striktního výkladu upouštělo a prohlížeče začaly tolerovat i ty nejhrubší prohřešky. Vládl, jak jsem již řekl, chaos. Tagy se neuzavíraly, křížily se, atributy neměly hodnoty atd. XHTML řadí zpátečku a pokouší se o pravý opak : uzavírejte všechny tagy, nekřižte elementy, atributům dávejte vždy hodnoty do uvozovek apod.

Vše je ale podstatně složitější než by se mohlo zdát.

Můj osobní názor je, že XHTML tlačí HTML někam, kde nemá co pohledávat a dělá z něj něco co není. Ať standard říká to či ono, ať se v moudrých knihách píší o XHTML různé opěvné glosy, faktem zůstává, že HTML v povědomí široké veřejnosti má podstatně blíže k formátovacímu jazyku než k datovému metajazyku. Podíváme-li se na vývoj názvů tagů, bude tato skutečnost daleko jasnější. Zabydlely se prostě ve své vizuální podobě : oddělovač (horizontální čára), tabulka, obrázek atd. a naděje, že nová norma předělá toto pojetí tvorby stránek do nového - významového, má podle mě jen omezené šance na úspěch.

Ztrácíme totiž rozmanitost a detailnost HTML a získáváme jen velmi málo ze síly strukturovaného pojetí XML. Jakkoliv oddělíme myšlenku a vzhled, pořád budeme u starého známého formátovacího jazyka na www prezentace. Můžeme zakázat programátorům používat sto a jeden tag, můžeme je donutit používat <OBJECT/>místo <IMG/> na každý obrázek (XHTML 2.0), ale pojetí prostého formátování textu bude v kódu zakořeněné nadále.

Jiná věc je ovšem psaní webových aplikací pomocí čistého XML kódu za použití některých technik pokročilých stylů a transformací - tento směr bych zvolil já (samozřejmě, jen pokud to situace dovoluje). Jedině tak můžeme provést skutečnou analýzu aplikace ve světle XML. Pokud to jde, komunikujme přes elementy a vzhled nechme obrázkům.

Jakým způsobem se adresují data uvnitř XML dokumentu jsme si již řekli. Bylo by to ale dost zbytečné, kdybychom nedokázali ukázat na nějaký objekt mino - tj. v souboru jiném.

Odkazování dokumentů v prostředí HTML sloužilo především dvěma účelům. První z nich znamenal jednoduše řečeno "přiložení" cílového objektu k dokumentu právě zpracovávanému, typicky šlo o obrázek. V druhém případě jde o "odkaz" v klasickém slova smyslu, tedy "kliknu sem a dostanu se tam". Ačkoliv je účel psaní URL v těchto případech různý, v principu se jedná o stejnou akci.

To je jeden z aspektů standardu XLink. Nejjednodušeji si změnu vysvětlíme na srovnání klasického a nového pojetí. Uveďme příklad.

<ZDROJ xlink:type="simple" xlink:href="http://connect.cpress.cz" xlink:title="Časopis" xlink:show="replace" xlink:actuate="onRequest" />

Atribut type značí jednoduchý typ XLink odkazu a href má zde stejnou funkci jako v HTML - URL cílového objektu. Description je jednoduchý popis, který může sloužit například jako alternativní text k nezobrazenému obrázku (<IMG Alt="...">). Místo zobrazení zadáme parametrem show, replace, jak asi tušíte, nahradí aktuální dokument v prohlížeči novým. Vedle toho hodnota "embedded" zobrazí objekt přímo v dokumentu a "new" by znamenalo otevření nového okna. Konečně actuate značí KDY bude externí soubor zavolán (onRequest = při vyžádání (typicky klik), onLoad = při nahrání (automatické vložení např. obrázku) ). Nesmíme zapomenout uzavřít tag lomítkem.

Jak je vidět, má to řád.

Další novou věcí je možnost odkazování na více zdrojů najednou. Typ elementu dejme "extended" a jeho do jeho obsahu vpišme (XLink) elementy další, tentokrát s typem "locator". Pareser pochopí, že se odkazujeme na všechny "locator"s v "extended" obsažené.

Jak je vidět, "podpůrné" standardy dávají XML tu pravou sílu, jaká programátorům chyběla. Nehledě na to, že jsem na poskytnutém prostoru pokryl slabou polovinu z nich a to ještě velmi stručně. Pro dnešek bych povídání o XML ukončil. Po první ukázkové části jste dnes absolvovali krátký rychlokurz po příbuzných technologiích a standardech. O dalších možnostech si povíme v některém z dalších, volně navazujících článků.