}w


!"#$%&'()+,-./012345<yA|
MASARYKOVA UNIVERZITA V BRNĚ
FAKULTA INFORMATIKY

Transformace dat formátu XML

DocBook

BAKALÁŘSKÁ PRÁCE

Vladimı́r Schreiner

Brno, 2004
Prohlášenı́

Prohlašuji, že tato bakalářská práce je mým původnı́m autorským dı́lem, které jsem vypracoval
samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracovánı́ použı́val nebo
z nich čerpal, v práci řádně cituji s uvedenı́m úplného odkazu na přı́slušný zdroj.

Vedoucı́ práce: RNDr. Tomáš Pitner, Ph.D.

ii
Shrnutı́

DocBook je progresivnı́m a nadčasovým dokumentačnı́m formátem postaveným na XML. Práce

popisuje tento formát s důrazem na transformace DocBookových dokumentů do vizuálnı́ch
podob. Sekundárně mapuje možnosti perzistentnı́ho uchovávánı́ takto značkovaných dat a
společně s doprovodnou aplikacı́ poskytujı́ ucelený náhled na tento dokumentačnı́ model.

iii
Klı́čová slova

DocBook, XML, XSL, XSLT, FO

iv
Obsah

1 DocBook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Elektronické dokumenty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Vznik DocBooku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Transformace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 XSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 XSL Transformace (XSLT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Model průběhu XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Možnosti XSLT šalbony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3 XSLT modes v DocBooku . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4 Datový model XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.5 Výrazy nad XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.5.1 Výrazy XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.6 Výstup XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.7 XSLT v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.7.1 Model funkce XSLT procesoru . . . . . . . . . . . . . . . . . . . . 15
2.2.7.2 Implementace XSLT procesorů . . . . . . . . . . . . . . . . . . . . 17
2.3 Rozlišovánı́ entit a XML Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Formátovánı́ a formátovacı́ objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Konkrétnı́ možnosti vizualizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.1 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.2 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5.3 HTML Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.4 PDF a PS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.4.1 FO definované v XSL . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.4.2 FO systému LATEX . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Perzistence transformačnı́ch vstupů a výstupů . . . . . . . . . . . . . . . . . . . . . . . 22
3.1 XML:DB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 XML:DB v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1 XML:DB API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 HTTP komunikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3 XML:RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Aplikace DOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Model aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.1 Tasklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3 Instruction (Instrukce) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.4 DOPTransformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.5 Postprocesor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.6 IODescriptor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.7 Instruction Manager (Správce instrukcı́) . . . . . . . . . . . . . . . . . . . . 27
4.1.8 IOManager (Správce V/V) . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.9 Transformer Manager (Správce transformátorů) . . . . . . . . . . . . . . . 27
4.2 Koncepce V/V operacı́ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1 Klı́čové rysy Mavenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1.1 Project Object Model . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1.2 Závislosti a repositories . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.1.3 Plug-iny . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1
 4.3.2 Práce s Mavenem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.3 POM - Deskriptor projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Bibliografie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2
Předmluva

Informačnı́ boom, charakterizujı́cı́ přinejmenšı́m poslednı́ dvě dekády, s sebou přinášı́ obrov-
skou a neustále rostoucı́ masu softwaru. Nedı́lnou částı́ takovýchto produktů je jejich doku-
mentace, která se měnı́ alespoň stejně dynamicky. Produkovat a distribuovat ji v papı́rové po-
době by bylo nejen nákladné a náročné, ale předevšı́m nesmyslné. Situace tedy otevı́rá prostor
dokumentům elektronickým. Oproti konvenčnı́m metodám vzniká při jejich použitı́ zásadnı́
problém: Jakým způsobem zobrazit informace o obsahu a vzhledu do binárnı́ soustavy použı́-
vané počı́tači? Odpovědı́ na tuto otázku je nepřeberné množstvı́ navzájem většinou naprosto
nekompatibilnı́ch formátů - tato situace ovšem nutně způsobuje určitý informačnı́ chaos. Cesta
ven vede jedině přes striktnı́ dodržovánı́ nadefinovaných standardů a doporučenı́.
Masově rozšı́řeným a respektovaným doporučenı́m je Extensible Markup Language (XML),
definovaný konsorciem W3C1 . XML se sice netýká přı́mo dokumentačnı́ch systémů (jeho mož-
nosti jsou mnohem širšı́), ovšem jednou z nejúspěšnějšı́ch oblastı́ jeho použitı́ se stal DocBook.
Práce si dává za cı́l poskytnout obecný náhled na problematiku elektronických dokumentů
a zdůraznit přednosti modelů postavených na XML, tedy předevšı́m DocBooku, v kontrastu
s proprietálnı́mi, komerčně protlačovanými formáty. Prvnı́ část přibližuje čtenáři koncepci XSL,
masově uznávané rodiny doporučenı́ konsorcia W3C, která definuje transformace nad XML
dokumenty. S pomocı́ XSL lze elegantně a pohodlně prezentovat DocBookové dokumenty širo-
kým spektrem vizuálnı́ch podob. Druhá část se potom zabývá možnostmi efektivnı́ho ukládánı́
a sdı́lenı́ XML dat, jakožto nedı́lné součásti praktického použitı́ každého formátu. Do centra
pozornosti stavı́ technologii XML:DB.
Praktickou součástı́ práce je aplikace DOP, jež se snažı́ být univerzálnı́m a rozšiřitelným
nástrojem využı́vajı́cı́m popsané technologie k transformacı́m DocBookových dokumentů ze
škály možných vstupů do množiny formátů sloužı́cı́ch k různým prezentačnı́m účelům. Jejı́ ze-
vrubný popis poskytuje poslednı́ část práce. Detailnějšı́ a vı́ce prakticky orientované informace
potom nabı́zı́ www stránka aplikace2 .

1. http://w3c.org/TR/2004/REC-xml-20040204/
2. http://www.fi.muni.cz/˜xschrein/dop

3
Kapitola 1

DocBook

1.1 Elektronické dokumenty

Nutnost použı́vánı́ elektronických dokumentů vznikla jako reakce na dynamický vývoj ob-
lasti informačnı́ch technologiı́. Hlavnı́ výhodou takového dokumentu je, že respektuje mnohdy
jepičı́ život své platnosti a nezatěžuje okolı́, na rozdı́l od dokumentů papı́rových, velkým množ-
stvı́m zdrojů. Takový dokument lze poměrně efektivně a rychle měnit. Nesporným negativnı́m
důsledkem plynoucı́m z předchozı́ch pozitiv je pak, napřı́klad v kontrastu s knihou, minimálnı́
trvanlivost kulturnı́ hodnoty.
Základnı́mi vlastnostmi, které by dobrý dokumentačnı́ systém měl splňovat, jsou:

• transformovatelnost do širokého množstvı́ výstupů

• efektivně realizovatelné tematické vyhledávánı́

• snadná a pohodlná editace

• nadčasovost

Nejdostupnějšı́mi použı́vanými systémy jsou WYSIWYG editory. Tato řešenı́ disponujı́

pouze vlastnostı́ pohodlné editovatelnosti, jinak je doprovázı́ neflexibilita, neuniverzálnost
či nemožnost jakéhokoliv sémantického zkoumánı́ struktury. Procesory těchto formátů se navı́c
vyvı́jejı́ rychle, v důsledku čehož může být čtenı́ dřı́ve vytvořených dokumentů problémem.
Většina předevšı́m zapomı́ná na základnı́ vlastnost dokumentu, kterou je přenos informace.
V této situaci se nabı́zı́ použitı́ značkovánı́ DocBook. Toto řešenı́ přinášı́ koncepci vkládánı́
obsahu dokumentu mezi logické značky. V důsledku zı́skáme dokument s nadefinovanou
strukturou, na základě které je možné generovat téměř libovolný výstupnı́ formát a poměrně
pohodlně v nı́ vyhledávat. DocBookový dokument je na elementárnı́ úrovni (jako každé jiné
XML) typicky uložen v textovém souboru, nadčasovost tohoto formátu snad nenı́ potřeba
zdůrazňovat. DocBookové dokumenty lze editovat libovolným textovým či XML editorem,
k dispozici jsou navı́c kvalitnı́ WYSIWYG editory; vzhledem k textové povaze zdroje může být
navı́c produktem nějakého skriptu.
Mnohé o kvalitách DocBooku prozradı́ reference: Jako dokumentačnı́ formát je využı́ván
předevšı́m mnoha open-source projekty, mezi něž patřı́ některé linuxové distribuce, FreeBSD
nebo jazyk PHP.

1.2 Vznik DocBooku

DocBook vznikl roku 1991 iniciativou HaL Computer Systems a nakladatelstvı́ O’Reilly. Origi-
nálnı́m záměrem bylo vytvořit jednotné SGML značkovánı́ pro výměnu unixových dokumen-
tacı́. V roce 1994 přebı́rá kontrolu nad jeho sestavovánı́m skupina Davenport Group, původně
zřı́zená nakladatelstvı́m O’Reilly. To už se DocBook předevšı́m kvůli rostoucı́mu DTD dostává
do podvědomı́ většı́ho množstvı́ uživatelů a velkých společnostı́ (mezi zakládajı́cı́mi členy

4
 1.2. VZNIK DOCBOOKU

Davenport Group figurujı́ lidé z Novellu, Fujitsu, Hewlett-Packard aj.). DocBook začı́ná být
použı́ván pro generovánı́ tisknutelných výstupů.
Davenport Group zaniká roku 1998, iniciativa je předána výboru DocBook Technical Com-
mittee organizace OASIS, který se této činnosti věnuje dodnes. Portuje značkovánı́ i do XML
a vyvı́jı́ obě formy paralelně. V současné době je DocBook definován pomocı́ DTD pro XML
a SGML. K dispozici jsou ovšem i neoficiálnı́ verze pro RELAX NG a XML Schema. Přestože
je DocBook vhodný předevšı́m pro dokumentace k softwarovým a hardwarovým produktům,
jeho flexibilita umožňuje nasazenı́ při tvorbě téměř jakékoliv publikace.

5
Kapitola 2

Transformace

XML je doporučenı́m, které vzniklo z iniciativy konsorcia W3C1 . Dá se proto předpokládat, že
z produkce stejné instituce by mělo vzniknout i rozšı́řenı́ definujı́cı́ transformovatelnost, v kon-
textu DocBooku speciálně možnost realizace vizuálnı́ch (publikovatelných) podob dokumentu.
Tato myšlenka se jevı́ jako správná - rozšı́řenı́ se jmenuje XSL (Extensible Stylesheet Language).

Obrázek 2.1: Popisovaný transformačnı́ model

2.1 XSL

Jazyk XSL měl být původně pouze jakýmsi staršı́m a chytřejšı́m sourozencem CSS, postu-
pem času se ale vyvinul v mimořádně silný prostředek, který nabı́zı́ formátovánı́ prezentace
(tedy funčnı́ ekvivalent CSS) pouze jako zlomek celkové funkčnosti. Svou koncepcı́ umožňuje
dokonale odstı́nit datový obsah původnı́ struktury od prezentačnı́ složky, přičemž jediným

1. http://www.w3c.org

6
 2.2. XSL TRANSFORMACE (XSLT)

požadavkem, který je na tuto strukturu kladen, je dodrženı́ předem definovaného schématu

(tedy DTD, XML Schema, ...).
Celý proces je možné pozorovat ze dvou pohledů. Tı́m prvnı́m je transformace stromové
struktury (tree transformation). Ta zajistı́ pouze přeskupenı́ uzlů původnı́ho dokumentu na zá-
kladě množiny přepisovacı́ch pravidel definavaných šablonou. Podrobný popis této procedury
poskytuje pasáž XSL Transformace. Poněkud sofistikovanějšı́m pohledem je formátovánı́ (for-
mating), které v prvnı́ fázi postupem ekvivalentnı́m s tree transformation modifikuje stromovou
strukturu na strom jakýchsi formátovacı́ch objektů. Výstupem transformace je tedy strom for-
mátovacı́ch objektů, instrukcı́. Jedná se o zobrazenı́ původnı́ho XML do stromu definujı́cı́ho
pomocı́ univerzálnı́ch typografických elementů budoucı́ tvar vizuálnı́ podoby dokumentu.
V této podobě je dokument předložen do druhé fáze zpracovánı́ - řı́zenı́ se předává procesoru
formátovacı́ch objektů, který na základě stromu formátovacı́ch objektů renderuje patřičnou
vizuálnı́ podobu. Detailnějšı́ náhled na tento proces poskytuje sekce formátovánı́ a formátovacı́
objekty.

2.2 XSL Transformace (XSLT)

Jak ukazuje schematický graf transformovatelnosti XML dokumentů, potažmo i DocBooku,

XSLT jsou nevyhnutelným krokem při realizaci libovolné transformace podle modelu XSL,
následujı́cı́ sekce poskytuje náhled na klı́čové rysy.
XSLT je definicı́ syntaxe a sémantiky funkcionálnı́ho jazyka. Dokument popisujı́cı́ konkrétnı́
program tohoto jazyka se nazývá šablona (stylesheet) a plně vystihuje celou transformaci.
Zavádı́ totiž množinu přepisovacı́ch pravidel, která sestávajı́ z pravé strany (sloužı́ jako vzor)
v relaci s levou stranou (obraz vzoru). Meritem transformace je pak nahrazovánı́ vybraných
uzlů odpovı́dajı́cı́ch vzorům jejich obrazy.
Prvnı́ verze XSLT vznikla jako doporučenı́ konsorcia W3C v řı́jnu 19992 . Verze 1.0 je dosud
plně využı́vána, přestože W3C již vyvı́jı́ novou revidovanou verzi 2.0 (zatı́m je ve stadiu working
draft), která má za své hlavnı́ cı́le:

• zjednodušit integraci s XML Schema

• zjednodušit manipulaci s řetězci

• plně podpořit XML standardy

• zjednodušit použitı́

• zvýšit mı́ru interoperability

• zlepšit možnost internacionalizace

• zajistit zpětnou kompatibilitu

• zvýšit výkon procesorů

2. http://www.w3c.org/TR/xslt

7
 2.2. XSL TRANSFORMACE (XSLT)

POZNÁMKA

Zatı́mco XSLT procesory pro XSLT ver. 1.0 jsou pohodlně dostupné pro
velkou většinu modernı́ch programovacı́ch jazyků (a to i jako open source),
u XSLT ver. 2.0 tomu tak zdaleka nenı́. Důvod lze hledat jednak v možnosti
změn v XSLT 2.0, které je stále ve stadiu working draft, přı́padně v relativně
značném nárůstu velikosti tohoto dokumentu oproti verzi 1.0, což se zcela
jistě odrážı́ v komplikovanosti implementacı́.

Zásadnı́mi pojmy oblasti XSLT jsou source tree (XML strom reprezentujı́cı́ zdrojový do-
kument), result tree (výsledný XML strom) a stylesheet (styl definujı́cı́ přepisovacı́ pravidla
přı́slušné transformace).

2.2.1 Model průběhu XSLT

Source tree je konstruován za pomoci XML parseru tak, že jeho komponenty jsou vzhledem
k použitému datovému modelu vkládány do stromové struktury. V dalšı́ch fázı́ch tedy tato
struktura reprezentuje vstupnı́ dokument. Result tree je budován postupně v průběhu trans-
formace následujı́cı́m postupem:
Na počátku transformace je v množině přepisovacı́ch pravidel nalezeno pravidlo se vzorem
odpovı́dajı́cı́m kořenovému elementu struktury. Pro něj je instanciována nová šablona (tem-
plate), která je součástı́ budoucı́ho result tree. Šablona může obsahovat bud’ literály, které se
promı́tnou jako koncové elementy do výstupnı́ struktury, nebo elementy jmenného prostoru xsl
3 reprezentujı́cı́ instrukce pro dalšı́ zpracovánı́. Tyto instrukce jsou vyhodnoceny tak, že pokud

odkazujı́ na nějaký dalšı́ uzel, je pro něj nalezeno odpovı́dajı́cı́ přepisovacı́ pravidlo, je pro něj
instanciována a paralelnı́m způsobem zpracována nová šablona.
Z popsaného principu vyplývá, že ne všechny uzly, pro které existujı́ přepisovacı́ pravidla,
musı́ být za pomoci těchto pravidel transformovány. K přepisu je mimo existenci pravidla nutný
ještě odkaz (tedy předánı́ řı́zenı́) z některého zpracovávaného elementu. Drobným háčkem XSLT
je, že pokud šablona explicitně neuvádı́ pravidlo pro zpracovánı́ kořenového elementu, použije
se automaticky:
<xsl:template match=”/”>
<xsl:apply-templates/>
</xsl:template>

tedy všechny děti kořenového elementu jsou zpracovány.

Následujı́cı́ jednoduchý přı́klad ilustruje, jak transformace probı́há. Uvažujme jednoduchý
vstupnı́ DocBookový dokument:

<!DOCTYPE article PUBLIC ”-//OASIS//DTD DocBook XML V4.3//EN”

”http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd”>

<article>
<section id=”sekce_1”>
<title>Sekce</title>
<para>
Odstavec 1
</para>
</section>
</article>

3. Jmenný prostor xsl je charakterizován identifikátorem http://www.w3.org/1999/XSL/Transform

8
 2.2. XSL TRANSFORMACE (XSLT)

V prvnı́m přı́padě použijeme k jeho transformaci následujı́cı́ stylovou šablonu:

<xsl:stylesheet version = ’1.0’
xmlns:xsl=’http://www.w3.org/1999/XSL/Transform’>

<xsl:template match=”section”>
<div>
<xsl:text>[id sekce = </xsl:text>
<xsl:value-of select=”@id”/>
<xsl:text>]</xsl:text>

</div>
</xsl:template>

<xsl:template match=”title”>
<b> <xsl:value-of select=”./text()”/> </b>
</xsl:template>

<xsl:template match=”para”>
<p>
<xsl:value-of select=”text()”/>
</p>
</xsl:template>

</xsl:stylesheet>

Prvnı́m krokem při zpracovánı́ je výběr přepisovacı́ho pravidla pro kořenový element struk-
tury (v tomto přı́padě article), takové pravidlo však očividně neexistuje. Použije se tedy
zmı́něný rys, jenž při absenci přepisovacı́ho pravidla pro kořenový element automaticky zpra-
covává jeho děti. Jediným přı́mým potomkem kořenového elementu je section, pro něž
přepisovacı́ pravidlo existuje. Šablona je tedy instanciována a přı́slušné přepisovacı́ pravidlo je
vyhodnoceno. Během vyhodnocovánı́ jsou literály, jež nejsou instrukcemi, ponechávány jako
výstup (v tomto přı́padě pouze <div> a </div>), elementy xsl:text majı́ de facto stejný
efekt. Element xsl:value-of je nahrazen hodnotou atributu id elementu section. V tomto
mı́stě zpracovánı́ končı́, jelikož žádný dalšı́ přı́mý potomek kořenového elementu neexistuje a
element section nepředal řı́zenı́ žádnému ze svých potomků. Výstupem je tedy:
<div>
[id sekce = sekce_1]
</div>

Z XSLT šablony je ale zřejmé, že kromě přepisovacı́ho pravidla pro section existujı́ i dalšı́
pro elementy para a title. Aby je bylo možné použı́t, je nutné upravit pravou stranu pravidla
pro vzor section do následujı́cı́ podoby:
<xsl:template match=”section”>
<div>
<xsl:text>[id sekce = </xsl:text>
<xsl:value-of select=”@id”/>
<xsl:text>]</xsl:text>

<xsl:apply-templates/>
</div>
</xsl:template>

Instrukce xsl:apply-templates informuje XSLT procesor o požadavku přidat všechny

přı́mé potomky aktuálnı́ho uzlu (označovaného jako current node) do seznamu uzlů pro zpra-
covánı́ (current node list). Tı́mto způsobem jsou tedy zpracovány kromě uzlu section (do

9
 2.2. XSL TRANSFORMACE (XSLT)

current node list jej přidává kořenový element jako svého přı́mého potomka) i uzly title a
para. Výsledný dokument vypadá takto:

<div>
[id sekce = sekce_1]
<b>Sekce</b>

<p>
Odstavec 1
</p>
</div>

2.2.2 Možnosti XSLT šalbony

XSLT šablony jsou kompletnı́mi nosiči transformačnı́ informace. Syntaxe XSLT reprezentuje
de facto gramatiku nad abecedou elementů jmenného prostoru xsl a literálů (literály v tomto
kontextu nenesou žádnou informaci charakteru transformačnı́ instrukce), přičemž literály jsou
terminálnı́mi symboly této gramatiky. Tato sekce nabı́zı́ stručný syntaktický náhled na XSLT.
Kořenovým uzlem šablon je element xsl:stylesheet (přı́p. xsl:transform, tyto konstrukce jsou
synonymy). Definuje předevšı́m verzi použitého stylu, jehož je nezbytnou součástı́.
Základnı́mi stavebnı́mi kameny samotné šablony jsou potom elementy jmenného prostoru
xsl. Sémantiku nejpoužı́vanějšı́ch elementů uvádı́ následujı́cı́ přehled. Pro zvýšenı́ přehlednosti
jsou uvedeny v tematicky přı́buzných skupinách.

1. Elementy specifikujı́cı́ průběh zpracovánı́

• xsl:apply-templates - instrukce zpracovávajı́cı́ všechny přı́mé potomky aktuálnı́ho

uzlu
• xsl:call-template - způsobı́ volánı́ přepisovacı́ho pravidla s levostranným výrazem
odpovı́dajı́cı́m atributu name.
• xsl:template - definuje přepisovacı́ pravidlo

2. Elementy pro vzájemné kombinovánı́ stylů

• xsl:include - Nabı́zı́ jednoduchou možnost vloženı́ jiného stylu. Touto instrukcı́

ovšem nejsou řešeny konflikty vznikajı́cı́ např. z vı́cenásobných definic.
• xsl:import - Je sofistikovanějšı́ alternativou xsl:include. Kromě toho, že externı́ styl
vložı́ do stylu aktuálnı́ho, kontroluje, zda vkládánı́m nevznikajı́ nějaké kolize defi-
nic. Pokud ano, preferuje původnı́ hodnoty, tj. ty, které jsou definovány v původnı́m
stylu. Touto cestou je pohodlně možné přizpůsobit stávajı́cı́ styly naimportovánı́m
do stylu vlastnı́ho a předefinovánı́m klı́čových struktur (proměnných, přepisova-
cı́ch pravidel, ...).

3. Elementy pro vytvářenı́ nových výstupnı́ch uzlů

• xsl:attribute - Přidává do výstupnı́ struktury atribut. Jeho „nositelem“ může být

bud’ literál, nebo element vytvořený pomocı́ xsl:element.
• xsl:attribute-set - Vytvářı́ pojmenovaný seznam atributů. Atributy vznikajı́ přede-
všı́m jako produkt xsl:attribute. Takto definovaný seznam lze potom referencovat
jeho kvalifikovaným jménem.
• xsl:copy - Kopı́ruje aktuálnı́ uzel, bez potomků a atributů, do výstupnı́ struktury.

10
 2.2. XSL TRANSFORMACE (XSLT)

• xsl:element - Vkládá do výstupnı́ho stromu nový element.

• xsl:text - Do výstupnı́ho stromu vkládá řetězec literálů.
• xsl:value-of - Vyhodnocuje XSLT výraz a jeho výsledek vkládá do výstupnı́ struk-
tury.

4. Elementy podmı́nečného zpracovánı́

• xsl:choose - Obklopuje souvisejı́cı́ množinu instrukcı́ xsl:if a xsl:otherwise. V za-

žitějšı́m světě imperativnı́ch programovacı́ch jazyků se nejvı́ce podobá přı́kazu
switch.
• xsl:when - Představuje jednu větev xsl:choose. Jejı́ obsah je vyhodnocován, pokud
je výraz v atributu test pravdivý.
• xsl:otherwise - Větev xsl:choose prováděná, pokud žádná z předchozı́ch xsl:when
větvı́ nebyla provedena.
• xsl:for-each - Element cyklicky opakujı́cı́ vyhodnocovánı́ svého obsahu. Řı́dicı́
strukturou pro tento cyklus je seznam uzlů.
• xsl:if - Element provádějı́cı́ svůj obsah v závislosti na výsledku podmı́nky uvedené
v atributu test.

5. Element třı́děnı́

• xsl:sort - Univerzálnı́ třı́dicı́ konstrukce s netradičnı́ syntaxı́. Pokud je element

xsl:sort uveden jako přı́mý potomek xsl:apply-templates nebo xsl:for-each, je vý-
sledek výběru elementů těchto operacı́ nejprve setřı́děn. Kritéria třı́děnı́ specifikujı́
atributy xsl:sort.

6. Elementy pro definici proměnných - Oba dva elementy majı́ kromě „přepisovatelnosti“
všechny vlastnosti stejné. Platı́ v kontextu, ve kterém byly zavedeny, a jeho potomcı́ch;
po opuštěnı́ tohoto rozsahu zanikajı́.

• xsl:param - Definuje parametr. Jeho hodnota může být během zpracovánı́ měněna.
• xsl:variable - Definuje proměnnou. Jejı́ hodnota je neměnná. Tento pro proměnnou
poněkud netypický rys je důsledkem snahy autorů XSLT o dodrženı́ funkcionál-
nı́ho paradigmatu, které reaguje na situace primárně podle přepisovacı́ch pravidel,
ne podle aktuálnı́ho stavu proměnných.

7. Element modifikujı́cı́ výstup

• xsl:output - Element umožňujı́cı́ manipulovat s vlastnostmi výstupu. Vlastnosti

tohoto elementu popisuje sekce Výstup XSLT.

2.2.3 XSLT modes v DocBooku

Návrh XSLT přinášı́ prakticky velice dobře použitelný rys - módy (modes) . Tato vlastnost
umožňuje, aby byl vzor při vı́ce průchodech jinak zpracován, přičemž kritériem pro tato zpra-
covánı́ je použitý mód. Módem je kvalifikované jméno. Toto jméno se pak může vyskytnout
jako hodnota atributu mode elementu xsl:apply-templates, který - jak bylo popsáno -
předává pomyslné řı́zenı́ přı́mým potomkům aktuálnı́ho uzlu. Hodnota módu je pak porovná-
vána s hodnotou atributu mode u definicı́ přepisovacı́ch pravidel pro tyto potomky, přičemž

11
 2.2. XSL TRANSFORMACE (XSLT)

zpracovánı́ je provedeno pomocı́ pravidel, jejichž mód odpovı́dá. Naopak, pokud element
xsl:apply-templates žádný mód nedefinuje, použijı́ se pravidla bez uvedeného módu.
Touto metodou je možné použı́t jednu šablonu pro vı́ce účelů bez nutnosti nějakých zákroků
razantnějšı́ho charakteru.

2.2.4 Datový model XSLT

Datový model specifikuje, jakým způsobem jsou komponenty XML mapovány na stromovou
strukturu, která toto XML reprezentuje. XSLT přejı́má tuto strukturu od doporučenı́ XPath
(XPath je možné považovat za jakéhosi sourozence XSLT, jsou vyvı́jeny vesměs paralelně jako
vzájemně kooperujı́cı́), přičemž přidává některé funkčnı́ prvky.
Strom je sestaven jako množina uzlů (nodes), pro každý z nich je nutně definován:

• string value - řetězec popisujı́cı́ každý uzel. Některé typy uzlů tuto hodnotu přı́mo
obsahujı́, u jiných je počı́tána ze string-value jejı́ch potomků.

• expanded name - dvoudı́lný popisovač uzlu sestávajı́cı́ z lokálnı́ části (local part) a uri
jmenného prostoru (namespace URI), které může být prázdné.

• document order - na každém uzlu stromu je definováno pořadı́, které odpovı́dá po-
řadı́ výskytu prvnı́ho znaku tohoto uzlu v původnı́m XML. Toto uspořádánı́ zajišt’uje
korektnı́ reprezenzaci dokumentu.

• parent - každý uzel mimo kořenový má přiřazeného právě jednoho rodiče.

• descendants - uspořádaný seznam potomků.

Každý uzel stromové struktury je navı́c jednoho z následujı́cı́ch sedmi typů:

• root node - uzel reprezentujı́cı́ kořen stromové struktury. V ose jeho potomků nalezneme
mimo jiné i instrukce pro zpracovánı́ (Processing instructions) a komentáře (Comments),
které jsou definovány před začátkem a po konci těla dokumentu.

• element node - uzel, který existuje pro každý element původnı́ho dokumentu. Element
node může být identifikován v rámci dokumentu jedinečným ID, které odpovı́dá hod-
notě atributu typu ID pro přı́slušný element.

• text node - seskupujı́ všechny textové uzly včetně konstrukcı́ CDATA.

• attribute node - reprezentuje atribut elementu. Zajı́mavé je, že attribute node má ro-
diče (parent) v elementu, v rámci něhož je definován, kdežto element svoje atributy
reprezentované pomocı́ attribute nodes jako potomky (descendants) nedefinuje.

• namespace node - reprezentujı́ jmenné prostory (namespaces) platné v rozsahu ele-

mentu. Každý element má tedy přiřazenu množinu uzlů typu namespace node. Stejně
jako u attribute nodes platı́, že namespace nodes majı́ jako rodiče (parent) přı́slušný
element, opačná vazba ovšem neplatı́.

• processing instruction node - tı́mto typem uzlu jsou reprezentovány všechny instrukce
pro zpracovánı́ (processing instruction) mimo deklaraci typu dokumentu a deklaraci
XML, XSLT je ignoruje.

• comment node - reprezentanti všech komentářů vyskytujı́cı́ch se mimo deklaraci typu

dokumentu, XSLT je ignoruje.

12
 2.2. XSL TRANSFORMACE (XSLT)

2.2.5 Výrazy nad XSLT

Při použitı́ XSLT se uživatel často setkává s nutnostı́ použitı́ logické navigace či jakýchsi pseu-
dodotazů nad dokumentem, který je zpracováván. Typickou situacı́ může být výběr uzlů pro
zpracovánı́ na základě určitého kritéria. Pro podobné účely je nad XSLT použit jazyk XPath
(XML Path Language)4 . Jedná se o konstrukci primárně sloužı́cı́ k adresaci komponent XML
dokumentu, jazyk navı́c poskytuje možnost využitı́ některých základnı́ch funkcı́ pro práci s ře-
tězci (např. concat, substring, ...), čı́sly (sum, round, ...) a logickými hodnotami (not, true,
false, ...).

2.2.5.1 Výrazy XPath

Jazyk XPath definuje předevšı́m syntaxi a sémantiku výrazů, které mohou být použity. Ve své
univerzálnosti nabı́zı́ XPath poměrně širokou paletu funkcı́ a operátorů, pro použitı́ v XSLT
je ovšem nejzásadnějšı́ možnost použitı́ tzv. Location paths. Location Paths nabı́zejı́ stručnou
a přı́močarou alternativu k odkazovánı́ na různá mı́sta v dokumentu v závislosti na aktuálnı́
poloze v dokumentu (tedy aktuálnı́m kontextu), svou syntaxı́ můžou vzdáleně připomı́nat
jakousi pseudosyntézu navigace v systému souborů s jistou formou regulárnı́ch výrazů.
Location paths jsou výrazy, které jsou sestavené z jednoho a vı́ce navigačnı́ch kroků (Location
step). Seznam navigačnı́ch kroků je čten zleva doprava, přičemž každý krok sestavı́ na základě
svého kontextu množinu uzlů. Tu předává jako kontext svému následnı́kovi v seznamu. Pokud
takový řetězec (seznam) nezačı́ná lomı́tkem, mluvı́me o něm jako o relativnı́ cestě (Relative
location path). V takovém přı́padě tvořı́ kontext pro prvnı́ navigačnı́ krok v řetězci aktuálnı́
uzel. V opačném přı́padě je cesta absolutnı́ (Absolute location path) a je vyhodnocována od
kořenového uzlu struktury.
Navigačnı́ krok je elementárnı́ částicı́ vyhodnocovánı́ location path. Jeho výsledek závisı́ na
třech komponentách.
Tou prvnı́ jsou osy, které usnadňujı́ orientaci mezi úrovněmi struktury vzhledem k aktuál-
nı́mu kontextovému uzlu.
• ancestor - osa seskupujı́cı́ všechny předky v rámci stromové struktury, pro kořenový
uzel je prázdná
• ancestor-or-self - rozšı́řenı́ osy ancestor o aktuálnı́ kontextový uzel
• attribute - osa atributů kontextového uzlu
• child - osa přı́mých potomků uzlu
• descendant - osa seskupujı́cı́ všechny potomky aktuálnı́ho kontextového uzlu, tj. přı́mé
potomky, přı́mé potomky přı́mých potomků, ...
• descendant-or-self - osa descendant rozšı́řená o kontextový uzel
• following - osa souvisejı́cı́ s pořadı́m ve struktuře, seskupuje všechny později definované
uzly kromě přı́slušnı́ků osy descendant, attribute nodes a namespace nodes
• following-sibling - obsahuje všechny později definované uzly na stejné úrovni - souro-
zence
• namespace - osa jmenných prostorů platných v aktuálnı́m kontextu. Pro jmenné prostory
je nutné zavádět vlastnı́ osu, jelikož (jak bylo uvedeno v popisu modelu) nejsou potomky
přı́slušného elementu

4. http://www.w3c.org/TR/xpath

13
 2.2. XSL TRANSFORMACE (XSLT)

• parent - obsahuje rodiče kontextového uzlu, pokud tento uzel rodiče má

• preceding - osa seskupujı́cı́ všechny dřı́ve definované uzly mimo přı́slušnı́ky osy ances-
tor, attribute nodes a namespace nodes

• preceding-sibling - osa všech dřı́ve definovaných sourozenců

• self - obsahuje pouze kontextový uzel

Druhou složkou navigačnı́ho kroku jsou node testy (node tests). Node testem je de facto kvalifi-
kované jméno (jméno včetně jmenného prostoru) uzlu(ů), který má být z přı́slušné osy vybrán.
Klı́čovým kritériem výběru je také typ tohoto uzlu. Pro každou osu je totiž definován typ jejich
prvků (principal node type), který se musı́ shodovat s typem vybı́raného elementu. Typy jsou
vzhledem k osám následujı́cı́:

• typ attribute pro osu attribute

• typ namespace pro osu namespace

• typ element pro ostatnı́ osy

Mı́sto kvalifikovaného jména je navı́c možné použı́t symbol *, což znamená výběr všech dostup-
ných uzlů odpovı́dajı́cı́ho typu kontextového uzlu. Ekvivalentně se dajı́ použı́t funkce text,
comment, processing-instruction s eventuálnı́m parametrem reprezentujı́cı́m jméno in-
strukce pro zpracovánı́ a node pro výběr všech dostupných uzlů daného typu.
Poslednı́ možnostı́ filtrovánı́ výsledku jsou predikáty. Predikátem může být jakýkoliv výraz
jazyka XPath ve své nejobecnějšı́ podobě. Pokud je návratovou hodnotou logická hodnota, je
chovánı́ intuitivnı́. Jedná-li se o čı́slo, pak je výraz platný pokud čı́slo odpovı́dá pořadı́ uzlu
v kontextu. Ostatnı́ typy návratových hodnot jsou zobrazovány na dvouprvkovou množinu
s true/false pomocı́ XPath funkce boolean().
Množina uzlů, kterou navigačnı́ krok produkuje jako výstup, je sestavena tak, že jsou
nejdřı́ve vybrány uzly na přı́slušné ose, poté jsou odstraněny ty, které neprojdou node testy.
Poslednı́m kritériem výběru je iterativnı́ filtrovánı́ přes predikáty.
Uvedená koncepce syntaxe je sice puntičkářsky přesná, pro běžné použitı́ ovšem mı́rně
neohrabaná. Proto byla do syntaxe jazyka XPath zavedena jistá zjednodušenı́:

• osa child je považována za implicitnı́, proto při navigaci v této ose může být jejı́ název
vynechán

• při navigaci v ose attribute lze namı́sto attribute:: použı́t pouze symbol @

• použitı́ // reprezentuje množinu všech uzlů struktury, nahrazuje tedy neohrabaný výraz
/descendant-or-self::node()/

• symbol . nahrazuje odkaz na kontextový uzel, tedy self::node()

• symbol .. nahrazuje odkaz na rodiče kontextového uzlu, jež v původnı́ syntaxi repre-
zentuje výraz parent::node()

Pro ilustraci použitı́ location paths a zjednodušené syntaxe je uvedeno několik přı́kladů:
výběr druhého odstavce (v DocBooku reprezentovaného elementem para) kontextového
uzlu původnı́ a zjednodušenou sytaxı́

child::para[position()=1]
para[position()=1]

14
 2.2. XSL TRANSFORMACE (XSLT)

výběr přı́mého potomka se jménem chapter a atributem title o hodnotě Introduction

child::chapter[child::title=’Introduction’]
chapter[@title=’Introduction’]

výběr přı́mých potomků jménem chapter, kteřı́ majı́ přı́mého potomka title

child::chapter[child::title]
chapter[title]

2.2.6 Výstup XSLT

Volitelnou, avšak silně doporučovanou vlastnostı́ XSLT procesorů je možnost ovlivnit formát
svého výstupu pomocı́ přepı́načů přı́mo v těle transformačnı́ šablony. Tento rys následně umož-
ňuje nadstavbovým aplikacı́m pohodlnou cestou ovlivňovat výstup procesoru bez nutnosti
nějak dále jej filtrovat. XSLT pro tento účel definuje element xsl:output, který se může vy-
skytnout jako top-level (tj. přı́mý potomek elementu xsl:stylesheet). Výstup je ovlivňován
následujı́cı́mi atributy tohoto elementu:

• method - Je nejdůležitějšı́m modifikátorem výstupu. Nabývá bud’ hodnot xml, html,

text, pro které definuje standardnı́ chovánı́, nebo libovolného kvalifikovaného jména
identifikujı́cı́ho nestandardnost.

• version - Specifikace verze výstupnı́ metody

• encoding - Nabı́zı́ možnost změnit kódovánı́, povolené hodnoty atributu (tedy znakové
sady) jsou implementačně specifické

• omit-xml-declaration - Vzhledem k hodnotě argumentu vynechává deklaraci XML na

začátku výstupnı́ho dokumentu.

• standalone - Pokud je atribut nastaven na yes, vložı́ XSLT procesor do dokumentu jeho
deklaraci

• doctype-public - Specifikuje veřejný identifikátor DTD

• doctype-system - Specifikuje systémový identifikátor DTD

• cdata-section-elements - Specifikuje seznam elementů, jejichž textový obsah je uzavřen

do sekce CDATA

• indent - Nastavuje možnost odsazovánı́ ve výsledném dokumentu, která je vhodná pro

čtenı́.

• media-type - MIME content type výsledného dokumentu

2.2.7 XSLT v praxi

2.2.7.1 Model funkce XSLT procesoru
Realizaci XSLT transformacı́ zajišt’uje XSLT procesor. Jedná se o aplikaci, která na základě XML
souboru a XSLT šablony produkuje výstupnı́ XML strukturu.
Aplikace musı́ nejdřı́ve zobrazit XML soubor s šablonou a vstupem do nějaké pamět’ové
struktury. K tomuto účelu sloužı́ komponenta nazývaná tree constructor. Jejı́mi subkom-
ponentami jsou XML parser, který na základě čteného vstupu produkuje události SAX; jejich

15
 2.2. XSL TRANSFORMACE (XSLT)

Obrázek 2.2: Schéma funkce XSLT procesoru

konzumentem je druhá komponenta - tree builder. Během procesu parsovánı́ dokumentu

je řešen problém rozpoznávánı́ externı́ch entit, na které se může zdrojový dokument pro za-
chvánı́ modularity celého modelu odkazovat. Entitou v tomto kontextu může být např. DTD,
jmenný prostor nebo pasáž samotného zdroje odkazovaná pomocı́ XInclude. Zajı́mavým řeše-
nı́m tohoto problému jsou XML Catalogs (viz. Rozlišovánı́ entit a XML Catalogs).
Parsing umožňuje odhalit chyby ve struktuře XML, a to jak správnou konstrukci (well-
formness), tak i validitu (validity) podle definovaného DTD.
V dalšı́ fázi je nutné upravit pamět’ový obraz stylové šablony pro použitı́ při samotné trans-
formaci. Komponenta zajišt’ujı́cı́ tuto činnost se nazývá stylesheet compiler. Navzdory
svému jménu neprodukuje žádnou formu binárnı́ho kódu. Docházı́ při nı́ zejména k vyhod-
nocenı́ XPath výrazů, přiřazenı́ jmen proměnným a v neposlednı́ řadě k odhalenı́ většiny
syntaktických chyb na úrovni XSLT (např. pokud typ výrazu atributu select u xsl:for-
each nenı́ seznamem uzlů). Tı́mto procesem zı́ská aplikace strukturu decorated tree, která je
připravená k realizaci transformacı́. Jelikož je přı́stup k nı́ read-only, je možné použı́vat ji vı́ce
než jednou a ušetřit tak netriviálnı́ čas spotřebovaný při jejı́ konstrukci.
Samotnou transformaci zajišt’uje stylesheet interpreter. Na základě modelu popsa-
ného v části Model průběhu XSLT produkuje cı́lový dokument. Většinou použı́vá nějakou
podpůrnou strukturu sloužı́cı́ k vyhledávánı́ vhodných přepisovacı́ch pravidel.
Poslednı́m účastnı́kem procesu je komponenta outputter, která shromáždı́ všechny po-

16
 2.3. ROZLIŠOVÁNÍ ENTIT A XML CATALOGS

třebné informace z pamět’ové reprezentace cı́lové stromové struktury a konstruuje z nich vý-
sledný výstupnı́ datový proud. Jako taková může brát ohled na formát výstupu, použı́t např.
jiné rysy pro HTML a XML výstup.

2.2.7.2 Implementace XSLT procesorů

Implementacı́ XSLT pro modernı́ programovacı́ jazyky existuje poměrně velké množstvı́.
Následujı́cı́ přehled uvádı́ rysy nejběžněji použı́vaných:

• Xalan
- vyvı́jen nadacı́ Apache
- verze pro Javu a C++
- implementuje XSLT 1.0, XPath 1.0
- open-source
• Saxon
- javová aplikace
- open source
- XSLT 1.0, 2.0 (verze 2.0 nekomerčnı́ bez podpory XML Schema)
- XPath 1.0, 2.0 (verze 2.0 nekomerčnı́ bez podpory XML Schema)

• Sablotron
- implementován v C++
- wrappery pro použitı́ v mnoha skriptovacı́ch jazycı́ch (Perl, PHP, Ruby, ...)
- XSLT 1.0
- XPath 1.0
- open-source
• XT
- javová implementace
- nekompletnı́ XSLT 1.0
- rychlá implementace

• libxslt
- knihovna jazyka C, možnost použitı́ z přı́kazové řádky (xsltproc)
- zakomponovaná podpora XML Catalogs
- XSLT 1.0
- XPath 1.0

2.3 Rozlišovánı́ entit a XML Catalogs

Koncepce XML dovoluje autorům a návrhářům těchto struktur zachovávat modularitu refe-
rencovánı́m externı́ch entit, předevšı́m definic DTD. Touto metodou je docı́leno univerzálnosti
použitı́. Komplikace nastává v situaci, kdy referencovaný zdroj nenı́ kvůli nefunkčnosti nebo
nedostupnosti přenosového média k dispozici. Nepřı́jemná může být také nutnost čı́st celý
externı́ dokument znovu při každém použitı́ aplikace (např. XML validátoru).
Možným řešenı́m tohoto problému je referencovánı́ pomocı́ symbolických jmen namı́sto
adresace. XML definuje možnost použitı́ veřejných identifikátorů (public identifiers), jinou
možnostı́ jsou URN (Universal Resource Names) - podmnožina URI. Obě alternativy jsou
postaveny na koncepci jedinečného identifikátoru zdroje, který neřı́ká nic o fyzickém umı́stěnı́
konkrétnı́ho souboru.

17
 2.4. FORMÁTOVÁNÍ A FORMÁTOVACÍ OBJEKTY

K přiřazenı́ adresy takovémuto jménu sloužı́ entity resolver. Zažitým a nejčastěji použitým
je entity resolver OASIS Catalogs vyvı́jený OASIS Entity Resolution Technical Committee5 .
Ten, pokud je korektně svázán s XML parserem, nahrazuje reference na entity těmi, které jsou
nadefinovány v jeho konfiguračnı́ch souborech - katalozı́ch. Katalog obsahuje jednak definici
chovánı́ resolveru při vyhledávánı́ v něm, klı́čovou složkou je pak množina záznamů mapu-
jı́cı́ch veřejné identifikátory a URN na přı́slušná URI. Touto cestou mohou být centralizovaně
nastavovány zdroje externı́ch entit.
V současné době pracuje tento výbor na sestavenı́ standardnı́ho formátu. Prozatı́m jsou
použı́vány následujı́cı́:

• OASIS XML Catalogs - formát popisujı́cı́ mapovánı́ symbolických referencı́ na URI

pomocı́ značkovánı́ XML. Následujı́cı́ přı́klad syntaxe mapuje veřejný identifikátor Do-
cBookového DTD na konkrétnı́ soubor:
<public publicId=”-//OASIS//DTD DocBook XML V4.3//EN”
uri=”docbookx.dtd”/>

• OASIS TR9401 Catalogs - formát s podobnou strukturou jako XML Catalogs, ovšem bez
přı́slušného značkovánı́ na čistě textové bázi. Následuje sémanticky stejná konstrukce
jako u XML Catalogs, podobnost se značnovaným dokumentem je zřejmá:
PUBLIC ”-//OASIS//DTD DocBook XML V4.3//EN” ”docbookx.dtd”

2.4 Formátovánı́ a formátovacı́ objekty

Druhou fázı́ modelu XSL je generovánı́ konkrétnı́ch vizuálnı́ch výstupů na základě formáto-
vacı́ch objektů. V tomto stadiu se proces dostává z oblasti sémantického značkovánı́ spı́še do
oblasti typografie, popis je transformován v prezentaci.
Pojem formátovacı́ objekt je poměrně ošidným, může nabývat mnoha různých podob.
Obecně se ale jedná o typografickou abstrakci popisujı́cı́ formát svého obsahu. Přestože exis-
tuje definice standardnı́ch formátovacı́ch objektů, je samozřejmě možné použı́t formát vlastnı́.
Vše záležı́ na stylu použitém při XSLT transformaci. Jako přı́klady je možné uvést LATEXový
zdrojový kód (jeho značky nejsou navı́c ani formátu XML), přı́padně HTML, které se poně-
kud nezdravě vyvinulo do značkovánı́ popisujı́cı́ho jak strukturu, tak vzhled. Formátovacı́m
procesorem HTML je potom prohlı́žeč.
Standardnı́ návrh formátovánı́ a struktury formátovacı́ch objektů popisuje přı́mo dopo-
ručenı́ W3C týkajı́cı́ se XSL6 . Výsledku je dosaženo konstrukcı́ stromu oblastı́ (area tree) -
kompletnı́ho popisu geometrického rozvrženı́ budoucı́ho dokumentu. Area tree je konstruo-
ván na základě stromu formátovacı́ch objektů, který vzniká XSLT transformacı́ a je sestaven
z elementů definovaných jmenným prostorem xsl7 . Struktura area tree nenı́ konstruována jed-
noprůchodově, vzniká upřesňovánı́m informacı́ na základě zpracovaného obsahu.

2.5 Konkrétnı́ možnosti vizualizace

Naprosto zásadnı́m rysem, který stavı́ DocBook do pozice velmoci na mapě dokumentačnı́ch
systémů, je kardinalita množiny generovatelných výstupů. To, že samotný dokument nespe-
cifikuje nic o formátovánı́ budoucı́ vizuálnı́ podoby, umožňuje odstı́nit veškerou formátovacı́

5. www.oasis-open.org/committees/entity/
6. http://www.w3.org/TR/xsl
7. http://www.w3.org/1999/XSL/Format

18
 2.5. KONKRÉTNÍ MOŽNOSTI VIZUALIZACE

aktivitu od logické struktury dokumentu. Tato sekce poskytne náhled na konkrétnı́ řešenı́ trans-
formacı́ DocBookových dokumentů do vizuálnı́ch podob v závislosti na výstupnı́m formátu.
Klı́čovou sekcı́ transformace DocBookového dokumentu je, jak již bylo zmı́něno, XSLT
transformace do patřičných formátovacı́ch objektů. Použitý styl tedy do značné mı́ry definuje,
jakým směrem se bude transformace ubı́rat. Kvalitnı́ a dobře přizpůsobitelnou sadu XSLT
stylů vyvı́jı́ sám autor DocBooku Norman Walsh. Pomocı́ těchto stylů je možné produkovat:
standardnı́ FO, HTML, XHTML, HTML help, Java help. Využitı́ těchto stylů bude popisovat
prvnı́ část této sekce.

2.5.1 HTML
HTML (HyperText Markup Language) je konkrétnı́m přı́padem úspěšné aplikace značkovacı́ho
jazyka, přestože v době svého vzniku vládl ještě rodič XML, totiž SGML. Původnı́ koncepcı́
bylo vytvořit formát pro psanı́ technických dokumentacı́. Přidánı́m podpory hypertextu a
multimediálnı́ch rozšı́řenı́ motivovalo řadu prodejců softwaru k učebnicovému zneužı́vánı́
tohoto formátu. Striktně formálnı́ a do značné mı́ry puritánské konsorcium W3C tento fakt
těžce nese a reaguje novými, přı́snějšı́mi doporučenı́mi. Bez ohledu na to jde o formát, který
byl rozmachem Internetu katapultován do pozic, o jakých by se mu dřı́ve ani nezdálo. Jeho
rozšı́řenı́ je dáno předevšı́m následujı́cı́mi aspekty:

• HTML klient (prohlı́žeč) je aplikacı́, která je dostupná prakticky pro všechny platformy.
Autor HTML dokumentu si může být jistý téměř „univerzálnı́“ čitelnostı́.

• Jednoduchost použitı́ a velké množstvı́ dostupných a user-friendly WYSIWYG editorů

přibližujı́ tento formát laikům.

• HTML dokumnety neobsahujı́ přı́liš mnoho metadat, tj. vzhledem ke svému obsahu
nejsou přı́liš velké

Jelikož je HTML pouze aplikacı́ XML, postačuje pro transformaci patřičná XSLT šablona.
HTML tagy výsledného dokumentu jsou totiž formátovacı́mi objekty, pomocı́ kterých prohlı́-
žeč renderuje zobrazovaný obsah. K HTML transformacı́m sloužı́ styl html/docbook.xsl
(relativně vzhledem ke kořenovému adresáři instalace balı́ku).
V situacı́ch jako prezentace může přijı́t vhod i styl html/chunk.xsl - ten zajistı́ mimo
transformace do HTML i patřičné rozdělenı́ do vzájemně odkazovatelných souborů. Použitı́ to-
hoto stylu je nepřı́jemné v tom, že na rozdı́l od šablon produkujı́cı́ch pouze jeden soubor ukládá
svůj výstup do aktuálnı́ho adresáře, ne tam, kam jej naviguje výstupnı́ parametr procesoru.
Generovaným výstupům lze samozřejmě přiřadit kaskádové styly, přičemž lze využı́t toho,
že Walshovy styly generujı́ u některých html tagů atribut class, jehož hodnotou je název Doc-
Bookové struktury, z nı́ž byl pořı́zen. Obdržený výsledek bude kromě syntaktické korektnosti
oslňovat i pohledným designem.

2.5.2 XHTML
XHTML (Extensible HyperText Markup Language) je dalšı́ aktivitou W3C8 ; Souvisı́ se snahou
konsorcia přiblı́žit HTML jeho kořenům, kterými je značkovánı́ bez ústupků postavené na XML
(původně SGML). XHTML je HTML 4 modifikované tak, aby dodržovalo doporučenı́ XML. Od
této aktivity si W3C slibuje předevšı́m kompatibilitu s XML nástroji.
Transformace do XHTML je realizovatelná použitı́m stylu xhtml/docbook.xsl a xhtml/
chunk.xsl s významem obdobným jako u HTML transformacı́.

8. http://w3c.org/TR/xhtml1

19
 2.5. KONKRÉTNÍ MOŽNOSTI VIZUALIZACE

2.5.3 HTML Help

Formát HTML Help je proprietálnı́ záležitostı́ Microsoftu, který jej doporučuje jako ideálnı́
médium k šı́řenı́ dokumentacı́ k softwaru a podobné interaktivnı́ elektronické literatury. Právě
naprostá platformnı́ závislost je jeho největšı́ slabinou. Nicméně uživatelé Windows určitě
ocenı́ styl htmlhelp/htmlhelp.xsl, generujı́cı́ přı́slušnou strukturu formátovacı́ch objektů. Tento
polotovar je do výsledné podoby nutné zkompilovat např. HTML Help Workshopem9 , který je
zdarma dostupný na webu Microsoftu.

2.5.4 PDF a PS
Nejelegantnějšı́m demonstracı́ možnostı́ DocBooku je zcela jistě transformace do tisknutelné
formy. Pohled na dokonale vysázený a zalámaný dokument na chvilku navodı́ utopickou vizi
světa prostého sazečů zı́skavšı́ch svoji kvalifikaci několikaminutovou instalacı́ kancelářského
balı́ku. Uvádı́m dvě cesty, kterými se dá kýžená iluze navodit.

2.5.4.1 FO definované v XSL

Prvnı́ možnostı́ je použı́t standardnı́ formátovacı́ objekty definované konsorciem W3C v do-
poručenı́ XSL 1.0. Styl pro trasformaci do standardnı́ch formátovacı́ch objektů je k nalezenı́ ve
zmiňovaném balı́ku Normana Walshe jako fo/docbook.xsl. Nezanedbatelná je v tomto přı́-
padě množina nastavenı́ (reprezentovaná elementy xsl:param), jimiž může uživatel výstup
ovlivnit. V tomto mı́stě je nutné zvolit vhodný generátor PDF/PS, který do značné mı́ry určuje
kvalitu obdrženého výstupu.
Volba může padnout na FOP (Formatting Object Procesor)10 . Jedná se o produkt projektu
Apache, což je v mnoha přı́padech puncem kvality. FOP toto pravidlo nerespektuje úplně
striktně. Zde je přehled jeho rysů:
+ plně javová implementace je zárukou platformnı́ nezávislosti
+ široké spektrum výstupnı́ch formátů (PDF, PCL, PS, SVG, AWT, MIF, TXT)
+ dostupnost, projekt je open source
- neúplná podpora standardnı́ch formátovacı́ch objektů
- absence české lokalizace (nové verze umožňujı́ naimportovánı́ TTF fontů)
Dalšı́m produktem je XEP11 . To je aplikace kvalitnějšı́, nicméně komerčnı́. Je vyvı́jena spo-
lečnostı́ RenderX, která uvolňuje zdarma pouze testovacı́ verze použitelné pro značná omezenı́
jen pro testovacı́ účely:
+ javová implementace implikuje interoperabilitu
+ kvalitnı́ výstupy plynoucı́ z důsledného dodrženı́ XSL:FO
- komerčnı́ aplikace
- absence české lokalizace (je možné importovat fonty)
Celkově lze řešenı́ pomocı́ formátovacı́ch objektů považovat za řešenı́ dostupné a nepřı́liš
vzdálené oblasti XML.

2.5.4.2 FO systému LATEX

Druhou cestou je použitı́ stylů pro transformaci do LATEXového zdrojového kódu a následné
zpracovánı́ LATEXem. Toto řešenı́ poskytne zcela jistě nejkvalitnějšı́ výstup, který navı́c může
být uživatelm upraven (editacı́ vygenerovaného zdrojového kódu). Balı́k stylů pro generovánı́
LATEXových zdrojových kódů poskytuje např. projekt DB2LATEX12 . Postup lze charakterizovat

9. http://msdn.microsoft.com/library/tools/htmlhelp/chm/HH1Start.htm
10. http://xml.apache.org/fop/
11. http://www.renderx.net/Content/tools/xep.html
12. http://db2latex.sourceforge.net/

20
 2.5. KONKRÉTNÍ MOŽNOSTI VIZUALIZACE

následujı́cı́mi vlastnostmi:
+ Dokonalý výsledný efekt dosažený použitı́m „nadčasového“ sázecı́ho systému
+ Možnost modifikovat vygenerovaný LATEXový zdrojový kód
+ Všechny komponenty transformačnı́ho procesu jsou k dispozici v plné kvalitě zdarma
- Nutná částečná znalost LATEXu
- Nutná instalace LATEXu (oproti javovým aplikacı́m ne úplně triviálnı́ záležitost)
- Přı́stup poměrně vzdálený XML problematice
Tento přı́stup lze považovat za „labužnický“, lze s nı́m dosáhnout nejlepšı́ch výsledků, které
jsou částečně kompenzovány vyvinutým úsilı́m při seznamovánı́ se s problematikou.

21
Kapitola 3

Perzistence transformačnı́ch vstupů a výstupů

Rostoucı́ zájem o technologie postavené na XML přirozeně vedl k problému s perzistentnı́m

ukládánı́m většı́ho množstvı́ těchto dokumentů. Ukládánı́ takovýchto dat do souboru je vhodné
pro menšı́ struktury, při nárůstu datového objemu ovšem nutně narážı́me na problém pomalého
a neefektivnı́ho přı́stupu či vyhledávánı́.
Prvotnı́ myšlenka by mohla vést k nějakému způsobu mapovánı́ XML dokumentů do za-
žitého principu hierarchických, relačnı́ch nebo objektových databázı́. Ta je de facto správná,
jelikož je ale pokryta jednou větvı́ XML:DB, bude popsána později.

3.1 XML:DB

S cı́lem navrhnout koncepci databáze šité na mı́ru formátu XML přišla v roce 2000 iniciativa
XML:DB1 . Jejı́mi aktivitami jsou předevšı́m:
• diskuze o všech zásadnı́ch problémech databázı́ nad XML, z nich vznikajı́ přı́slušná
doporučenı́
• návrh databázového aplikačnı́ho rozhranı́
• návrh jazyka XUpdate pro modifikace XML dat
• jazyk SiXDML (Simple XML Data Manipulation Language), který má být jakýmsi ekvi-
valentem SQL známým z relačnı́ch databázı́. Navı́c definuje vlastnı́ API, které má být
modernějšı́ a vı́ce sofostikovanou alternativou standardnı́ho XML:DB API
• do budoucna je navržena i možnost zařadit do koncepce databáze i Access Control Listy
Iniciativa dále definuje tři možné modely XML databázı́:
• Nativnı́ (Native XML Database - NXD): Tato databáze je postavena na myšlence XML do-
kumentu jako elementárnı́ zpracovávané jednotky (paralela řádku u relačnı́ databáze).
Dále vyžaduje definici nějakého modelu, pomocı́ kterého data v dokumentu identifikuje
(elementy, atributy, PCDATA). Důležitou myšlenkou je odstı́něnı́ od konkrétnı́ imple-
mentace databázového enginu, data můžou být např. mapována na relačnı́ databázi
nebo filesystem.
• Připravenou (XML Enabled Database - XEDB): Koncepce vycházejı́cı́ z myšlenky kon-
verznı́ vrstvy nad libovolnou databázı́. Tato vrstva mapuje XML dokumenty na data
specifická pro danou databázi, v opačném směru z těchto dat konstruuje nový XML
dokument. Z popsaného postupu plyne, že výstupnı́ dokument nemusı́ být shodný
s dokumentem na vstupu. Tato koncepce poskytuje prostor autorů produktů třetı́ strany
(3rd party tools) vyvı́jet nadstavby nad robustnı́mi databázemi.
• Hybridnı́ (Hybrid XML Database - HXD): Databáze přichylujı́cı́ se k jednomu z před-
chozı́ch modelů v závislosti na požadavcı́ch klienta.

1. http://xmldb-org.sourceforge.net/index.html

22
 3.2. XML:DB V PRAXI

3.2 XML:DB v praxi

Jednou z nejoblı́benějšı́ch open-source implementacı́ nativnı́ XML:DB je databáze eXist2 . Jedná

se o plně javovou aplikaci, která může být spouštěna jako standalone server nebo jako aplikace
v rámci webového kontejneru. Dokumenty jsou ukládány do hierarchických kolekcı́ podob-
ných filesystému. Struktura až po úroveň elementů, atributů a textových uzlů je automaticky
indexována, což umožňuje rychlé a efektivnı́ vyhodnocovánı́ XPath/XQuery výrazů. Data-
báze navı́c implementuje i XUpdate. Z uživatelského hlediska je většinou zásadnı́m prvkem
aplikačnı́ rozhranı́. EXist nabı́zı́ - pokud je k němu přistupováno jako k serveru - následujı́cı́
možnosti komunikace.

3.2.1 XML:DB API

Jako aplikačnı́ rozhranı́ připravené přı́mo autory XML:DB by mělo být preferovanou metodou
pro komunikaci s databázı́. Jejı́ použitı́ zaručuje předevšı́m kompatibilitu, jakožto základnı́
prvek pro psanı́ flexibilnı́ch aplikacı́. Základnı́mi stavebnı́mi kameny tohoto komunikačnı́ho
modelu jsou ovladače databáze (Drivers), kolekce (Collections), zdroje (Resources) a služby
(Services), přičemž celý systém funguje v klientské aplikaci následovně:
Aplikace musı́ nejdřı́ve vytvořit instanci databázového ovladače. Jedná se o implementaci
rozhranı́ org.xmldb.api.base.Database dodanou výrobcem přı́slušné databáze . Tato
instance je předána třı́dě DatabaseManager, která zajišt’uje správu a distribuci ovladačů
vzhledem k definovaným identifikátorům.

//vytvořenı́ nové instance databázového ovladače pro eXist

Database db = new org.exist.xmldb.DatabaseImpl();

//registrace databáze statickou metodou třı́dy DatabaseManager

DatabaseManager.registerDatabase(db);

Uživatalská aplikace nynı́ může žádat DatabaseManager o poskytnutı́ kolekce pro přı́-
slušné URI. URI má strukturu xmldb:id databáze://adresa hostitele/databáze/kolekce, při-
čemž id databáze sloužı́ DatabaseManageru k identifikaci databázového ovladače. Kolekce je
potom přı́stupovým bodem pro samotnou komunikaci.

//Zı́skánı́ kolekce
Collection col =
DatabaseManager.getCollection(”xmldb:exist://localhost/exist/”);

Samotný dokument (tj. zdroj - resource) zı́skává aplikace z přı́slušné kolekce tak, že jej iden-
tifikuje pomocı́ cesty XML stromu, jejž databáze uchovává. Zdroj obecně může být nejen texto-
vého typu XMLResource, ale i binárnı́ho BinaryResource. Vzhledem k tomu, že předpoklá-
dáme práci s textovými DocBookovými dokumenty, můžeme přetypovat na XMLResource.

//zı́skánı́ konkrétnı́ho zdroje

XMLResource res = (XMLResource) col.getResource(”databaze/dokument.xml”);

Druhou možnostı́ je požádat o zcela novou množinu uzlů výrazem jazyka XQuery/XPath.
Schopnost dotazovánı́ obecně nenı́ nutnou součástı́ všech implementacı́ XML:DB API, eXist ji
však nabı́zı́. Je službou (Service), na jejı́ž dostupnost se má klientská aplikace možnost zeptat a
přizpůsobit tak své chovánı́.

2. http://exist.sourceforge.net/

23
 3.2. XML:DB V PRAXI

// pokus o zjı́skánı́ služby pro dotazy XPath verze 1.0

XPathQueryService service =
(XPathQueryService) col.getService(”XPathQueryService”, ”1.0”);

//vykonánı́ dotazu
ResourceSet result = service.query( queryString);

//iterace přes výsledky dotazu

ResourceIterator i = result.getIterator();

while(i.hasMoreResources()) {
Resource r = i.nextResource();
System.out.println((String)r.getContent());
}

3.2.2 HTTP komunikace

Nejjednoduššı́ alternativou, pomocı́ které je možné komunikaci uskutečňovat, je komunikace
prostřednictvı́m protokolu HTTP. Hlavnı́m přı́nosem tohoto modelu je předevšı́m rychlost (vše,
co musı́ webová komponenta serveru řešit, je parsing většinou ne přı́liš komplikovaného řetězce
požadavku, navı́c požadavek i odpověd’ obsahujı́ minimálnı́ množstvı́ metadat) a interoperabi-
lita (knihovny pro obsluhu HTTP spojenı́ jsou nedı́lnou součástı́ velké většiny programovacı́ch
jazyků, uživatel-konzument má možnost využı́t pro jednoduchý náhled na data libovolný pro-
hlı́žeč bez nutnosti instalovat speciálnı́ klientský software). Viditelnou nevýhodou je zřejmě
nemožnost využı́vat sofistikovanějšı́ služby nabı́zené databázı́.
Typicky se k odlišenı́ služeb serveru použı́vá použitá metoda HTTP požadavku:
• GET pro zı́skánı́ množiny dat

• PUT pro uloženı́ datové struktury, ta je zası́lána v těle požadavku

• POST nabı́zı́ možnost být univerzálně použit pro libovolnou situaci, která je popsána
strukturou v těle požadavku

• DELETE pro smazánı́ dokumentu(ů)

Klientská aplikace je informována o výsledku operace pomocı́ návratové hodnoty HTTP.

3.2.3 XML:RPC
Model XML:RPC3 vznikl jako specifikace umožňujı́cı́ aplikacı́m běžı́cı́m v různých prostředı́ch
a na různých operačnı́ch systémech komunikovat přes protokol HTTP s využitı́m XML. Ko-
munikace probı́há tak, že aplikace v roli klienta vytvořı́ XML dokument s předem definovanou
strukturou obsahujı́cı́ jméno volané vzdálené procedury společně s jejı́mi parametry, zašle jej
jako HTTP POST request serveru; procedura je patřičně vyhodnocena a opět jako XML zaslána
zpět klientovi.
EXist obsahuje široké spektrum vzdáleně volatelných procedur, které jsou definovány roz-
hranı́m org.exist.xmlrpc.RpcAPI. Vše, co potřebuje klientská aplikace, je implementace
XML:RPC. Následujı́cı́ ilustračnı́ přı́klad zı́skávánı́ jednoduchého dokumentu pomocı́ javové
XML:RPC implementace instituce Apache4 .
// nastavenı́ implicitnı́ho kódovánı́ komunikace
org.apache.xmlrpc.XmlRpc.setEncoding(”UTF-8”);

3. http://www.xmlrpc.com/
4. http://ws.apache.org/xmlrpc/

24
 3.2. XML:DB V PRAXI

// vytovřenı́ nové instance XML:RPC klienta pro dotaz nad aURL

XmlRpcClient xmlrpc = new XmlRpcClient( aURL );

// nastavenı́ některých parametrů, které budou brány

// v potaz při generovánı́ odpovědi
Hashtable options = new Hashtable();
options.put(”indent”, ”yes”);
options.put(”encoding”, ”UTF-8”);
options.put(”expand-xincludes”, ”yes”);
options.put(”highlight-matches”, ”elements”);

// vloženı́ parametrů do XML dokumentu požadavku

Vector params = new Vector();
params.addElement( pathToTargetXML );
params.addElement( options );

// generovánı́ a odeslánı́ požadavku, čekánı́ na odpověd’ -

// ta je typu String, protože getDocumentAsString vracı́ String
String xml = (String) xmlrpc.execute( ”getDocumentAsString”, params );

// vypsánı́ odpovědi na standardnı́ výstup

System.out.println( xml );

Obecně lze XML:RPC řešenı́ považovat za skvěle uplatnitelné vzhledem ke své interope-
rabilitě. Toto tvrzenı́ podporuje i fakt, že model XML:RPC využı́vá i eXistová implementace
XML:DB API.

25
Kapitola 4

Aplikace DOP

Aplikace DOP vznikla jako elektronická komponenta tohoto textu prakticky ilustrujı́cı́ popsaný
model transformacı́ DocBooku. Jejı́m hlavnı́m cı́lem je portabilita, rozšiřitelnost, schopnost
poskytnout pohodlné uživatelské rozhranı́ i možnost dávkového ovládánı́.
Celá aplikace je tedy demonstracı́ transformačnı́ho modelu XSL. Je komletně javová, XSLT
zajišt’uje transformačnı́ engine Saxon. Oproti standardnı́m konzolovým rozhranı́m XSLT pro-
cesorů integruje možnost využitı́ širšı́ palety použitelných vstupů a výstupů: soubor, množinu
souborů specifikovanou pomocı́ wildcards, URL a XML:DB zdroj. Přestože výchozı́m uživatel-
ským rozhranı́m je swingové GUI, nabı́zı́ se uživateli možnost použitı́ z přı́kazové řádky. Dı́ky
použitému systému lze generovat dávky, jež lze poté spouštět pomocı́ dávkového rozhranı́. Pro
parsovánı́ XML zdrojů je použı́ván parser Xerces2 (předevšı́m pro svou schopnost validovat
vstup), integrována je i podpora XML Catalogs.

4.1 Model aplikace

Funkčnost aplikace je zajištěna vzájemnou kooperacı́ mezi následujı́cı́mi komponentami:

4.1.1 Tasklist

Navzdory svému názvu nenı́ pouze seznamem objektů Task. Integruje v sobě předevšı́m en-
gine, který zajišt’uje shromážděnı́ všech potřebných informacı́ pro realizaci XSLT transformace
a na jejich základě transformaci realizuje. Navı́c umožňuje okolnı́m komponentám registraci
posluchače událostı́ typu DOPEvent, DOPListeneru. Do tohoto posluchače jsou zaznamená-
vány události souvisejı́cı́ s manipulacı́ obsahu Tasklistu stejně jako události při jeho zpracovánı́
(transformaci).

4.1.2 Task

Je v kontextu DOPu jakousi jednotkou zpracovánı́ - popisuje transformaci jednoho vstupu (který
může ovšem obsahovat vı́ce konkrétnı́ch dokumentů) na základě jedné instrukce. Obsahuje
předevšı́m reference na objekty popisujı́cı́ vstup, výstup a instrukci.

4.1.3 Instruction (Instrukce)

Komponenta popisujı́cı́ XSL transformaci. XSLT je reprezentována URL přı́slušné stylové ša-
blony, pomocı́ které bude transformace prováděna. Volitelnou součástı́ je pak definice URL
postprocesoru; jejı́ volitelnost vyplývá z možného přenesenı́ tohoto kroku na prohlı́žeč cı́lo-
vého formátu (přı́pad HTML). Instrukce navı́c eviduje seznamy parametrů XSLT transformace,
které ji ovlivňujı́ v duchu rozhranı́ TRaX, seznam výstupnı́ch parametrů předávaných transfor-
mátoru (Výstup XSLT) a eventuálně seznam parametrů postprocesoru.

26
 4.1. MODEL APLIKACE

4.1.4 DOPTransformer

Objekt, který obaluje transformer definovaný třı́dou javax.xml.transform.Transformer

realizujı́cı́ transformaci. Rozšiřuje schopnosti této třı́dy předevšı́m o možnost zamykánı́ (Saxo-
nová implementace javax.xml.transform.Transformer nenı́ připravena pro použitı́ ve
vı́ce vláknech, což by DOPu jinak činilo problémy) a manipulace s vlastnostmi.

4.1.5 Postprocesor

Komponenta, která se snažı́ vyřešit ošidný problém platformně nezávislé realizace zpracovánı́
formátovacı́ch objektů. Problémem je totiž široké spektrum možných procesorů formátovacı́ch
objektů v kontrastu s XSLT, které může být provedeno jednı́m XSLT procesorem. DOP řešı́
situaci použitı́m Antu - tato utilita umožňuje ze svých platformně nezávislých skriptů volat
libovolnou posloupnost operacı́, zvláště tedy spouštět procesor formátovacı́ch objketů. DOP
spouštı́ postprocesor volánı́m posloupnosti antových třı́d s URL přı́slušného popisovače. DOP
předává Antu následujı́cı́ parametry:

• from - jméno souboru s formátovacı́mi objekty, výsledek XSLT

• to - soubor, do kterého má být prezentace provedena, ten je poté zpracováván výstup-
nı́mi rutinami DOPu

• parametry postprocesoru definované použitou instrukcı́

4.1.6 IODescriptor

Obecná třı́da evidujı́cı́ informace nutné pro vytvořenı́ konkrétnı́ instance vstupnı́ nebo výstupnı́
procedury. Tento prostřednı́k mezi uživatelem a konkrétnı́ instancı́ vstupnı́ nebo výstupnı́ třı́dy
byl zaveden hlavně kvůli možnosti průhledněji zobrazit informace o přı́slušném zdroji do
souboru s definicemi. Obsahuje klı́č identifikujı́cı́ třı́du realizujı́cı́ operaci a seznam parametrů
pro korektnı́ funkčnost třı́dy (např. cestu k souboru, přı́stupové jméno do databáze, ...)

4.1.7 Instruction Manager (Správce instrukcı́)

Informace o instrukcı́ch, které jsou jinak pouze popisovači bez jakékoli funkčnosti, jsou aplikacı́
DOP při jejı́m spuštěnı́ načı́tány z konfiguračnı́ho souboru. Tyto informace shromažd’uje a
poskytuje ostatnı́m komponentám třı́da Instruction Manager.

4.1.8 IOManager (Správce V/V)

Podobnou funkci jako Instruction Manager má i IOManager. Koexistuje ve dvou instan-
cı́ch - pro vstup a výstup. Mimo evidenci popisovačů V/V, objektů IODescriptor, představuje
prostředek pro instancializaci konkrétnı́ch vstupně/výstupnı́ch třı́d.

4.1.9 Transformer Manager (Správce transformátorů)

Model funkce XSLT procesoru zmiňuje netriviálnı́ dávku systémového času, který je potřebný
pro přı́pravu funkceschopného transformátoru. Aplikace DOP zohledňuje tento aspekt třı́dou
Transformer Manager. Ta reaguje na žádosti okolnı́ch komponent a pro klı́če (kterými jsou
URL) vytvářı́ objekty DOPTransformer. Ty ovšem nejsou po použitı́ zahazovány, ale evido-
vány. Dalšı́ dotaz na shodné URL je proto vyhodnocen nepoměrně rychleji. Tento rys uživatel

27
 4.2. KONCEPCE V/V OPERACÍ

ocenı́ předevšı́m při dávkovém zpracovánı́ vı́ce zdrojů jednou šablonou nebo při zpracovánı́
opakovaném v rámci jednoho běhu aplikace.
Aplikace po svém spuštěnı́ parsuje konfiguračnı́ XML soubor a pomocı́ událostı́ SAX kon-
struuje obsah InstructionManageru a IOManagerů. Uživatel potom pomocı́ přı́slušného
rozhranı́ vytvořı́ novou instanci Tasklistu, na základě evidovaných instrukcı́ a specifiková-
nı́m parametrů vstupů a výstupů jej naplňuje Tasky.
K transformaci dojde spuštěnı́m metody process. Iterativně jsou procházeny všechny
Tasky. Zpracovánı́ Tasku začı́ná otevřenı́m zdroje a cı́le, následně je volán TransformerManager
s URL referencujı́cı́m přı́slušnou XSLT šablonu. Jelikož TransformerManager nenı́ připra-
ven pro vı́cevláknové použitı́, je možné, že nenı́ v danou chvı́li k dispozici. V tomto přı́-
padě aplikace čeká po dobu definovanou v konfiguračnı́m souboru a pokusı́ se přistoupit
k TransformerManageru znovu. Na úspěšně zapůjčený DOPTransformer reaguje Tasklist
jeho konfiguracı́ pomocı́ parametrů a vlastnostı́ výstupu. Úspěšná konfigurace je poslednı́m
krokem před spuštěnı́m samotné XSLT transformace. Ta může být spouštěna vı́cenásobně vzhle-
dem k možnosti vı́ce vstupnı́ch dokumentů (např. v důsledku použitı́ wildcards). Následuje
transformace. Předepisuje-li instrukce, podle nı́ž se transformuje, postprocesing je podle popsa-
ného modelu spuštěn Ant. Pro komunikaci s nı́m použı́vá DOP dočasné soubory, filesystémové
cesty k nim, upravené podle syntaxe použitého operačnı́ho systému, předává DOP antovému
skriptu proměnnými from a to.
Výsledek transformace je předán výstupnı́ třı́dě ke zpracovánı́, TransformerManageru je
vrácen DOPTransformer. Konstrukcı́ půjčovánı́ a navracenı́ je na úrovni TransformerManageru
zaručen nejen unikátnı́ přı́stup, tj. eliminace nežádoucı́ho vı́cevláknového přı́stupu, ale i mož-
nosti konfigurace DOPTransformeru bez obav o zásah do konfigurace použı́vané jiným vlák-
nem. Použité Tasklisty nemusı́ být záležitostı́ jednoho spušntěnı́. Aplikace obsahuje konstrukce
pro perzistentnı́ ukládánı́ Tasklistů do XML souborů lokálnı́ho filesystému.

4.2 Koncepce V/V operacı́

Myšlenka univerzálnosti vstupně/výstupnı́ho systému, který je dokonale odstı́něn od zbytku

aplikace, podnı́tila vznik následujı́cı́ho modelu.
Vstupnı́ i výstupnı́ třı́dy jsou popisovány konfiguračnı́m souborem aplikace. Ten definuje
jednak třı́du, která přı́slušnou definici implmentuje, a jednak seznam parametrů, které jsou
uživateli nabı́dnuty k popisu přı́slušného zdroje. Tento krok má jako svou stinnou stránku
možnost nekorektnı́ definice vzhledem k redundanci (parametry definované v konfiguračnı́m
souboru se lišı́ od těch skutečně použı́vaných třı́dou).
V kontrastu s tı́m ovšem nesvazuje ruce návrhářům nových vstupně/výstupnı́ch třı́d, navı́c
umožňuje použitı́ průhledného modelu referencı́ mezi XML soubory - Tasklist uložený jako
diskový soubor formátu XML obsahuje informace o nastavenı́ zdroje, jeho struktura korespon-
duje s definicı́ tohoto zdroje v konfiguračnı́m souboru aplikace.
Definici zdroje pro čtenı́ z XML:DB

<input classname=”dop.io.XMLDBResourceObtainer”>
<name>XMLDB</name>
<methodname_parameters>
<methodname_parameter name=”uri”
description=”URI databaze” necessary=”yes”/>
<methodname_parameter name=”username”
description=”uziv. jmeno” necessary=”no”/>
<methodname_parameter name=”password”
description=”heslo” necessary=”no”/>
<methodname_parameter name=”xpath”
description=”XPath cesta v DB” necessary=”no”/>

28
 4.3. MAVEN

<methodname_parameter name=”databaseImplClass”
description=”ovladac databaze” necessary=”yes”/>
</methodname_parameters>
</input>

Výstupnı́ třı́dy majı́ ještě jeden specifický rys. Vzhledem k popsané možnosti vı́ce vstupů
může být problém s jejich ukládánı́m. Rozhranı́ definované nad výstupnı́mi třı́dami proto
definujı́ metody multipleOutputSupport a initMultipleSupport, umožňujı́cı́ korektně
uložit vı́ce dokumentů v závislosti na jednom popsaném zdroji.

4.3 Maven

Nedı́lnou součástı́ vývoje aplikace DOP byl nástroj Maven1 . Jeho zevrubný popis považuji za
nutnou součást tohoto textu.
Maven, relativně nová akvizice projektu Jakarta, je nástrojem pro správu javových pro-
jektů. Poslánı́m této utility je předevšı́m automatizace děnı́ „okolo“ vyvı́jené aplikace, tedy
generovánı́ build skriptů, dokumentace, laděnı́, návaznostı́ na okolı́, atd. Tedy činnostı́, které
jsou stereotypnı́ a tudı́ž automatizovatelné. Maven přicházı́ s myšlenkou použitı́ jednoho sou-
boru pro kompletnı́ popis projektu. Nad tı́mto souborem operuje množina plug-inů zajišt’ujı́cı́
samotnou fukcionalitu.

4.3.1 Klı́čové rysy Mavenu

4.3.1.1 Project Object Model
Project Object Model (dále POM) je základnı́ strukturou zpracovávanou Mavenem. Typicky je
reprezentován souborem project.xml uloženým v kořenovém adresáři projektu. Jedná se
o XML strukturu, která poměrně důkladně zachycuje veškeré informace o projektu - v prvnı́
řadě údaje o názvu, verzi a autorech projektu, násedně popis závislostı́ a postup sestavovánı́
projektu. Na základě těchto dat může Maven nabı́dnout celkem pestrou paletu možných akcı́.
V prvnı́ řadě poskytuje přı́kazy pro vytvořenı́ adresářové struktury, sestavenı́ projektu, gene-
rovánı́ antových skriptů nebo spouštěnı́ testů. Už ne tak obvyklá je schopnost automatického
generovánı́ poměrně rozsáhlé dokumentace včetně webové prezentace a PDF dokumentu.

4.3.1.2 Závislosti a repositories

Poměrně vysoký komfort může Maven nabı́dnout uživateli v oblasti řešenı́ závislostı́. Ty jsou
unikátně nadefinovány v POM v oblasti vymezené elementy dependencies. Zde vyniká
jedna z největšı́ch přednostı́ Mavenu - možnost sdı́let často použı́vané balı́ky (typicky soubory
JAR) ve veřejném archivu. Pokud je potřeba použı́t některý balı́k, který nenı́ součástı́ javové
distribuce, stačı́ jej pouze popsat pomocı́ elementu dependency. Maven se jej pokusı́ najı́t ve
své lokálnı́ repository (typicky umı́stěné v $HOME/.maven/repository), pokud neuspěje,
kontaktuje některý z veřejných a pro tento účel vyhrazených archivů (implicitně se jedná
o http://ibiblio.org/maven, alternativnı́ archı́vy se samozřejmě dajı́ nastavit). Je-li odpovı́dajı́cı́
balı́k nalezen, stáhne jej Maven do archı́vu lokálnı́ho, odkud je nadále přı́stupný i pro ostatnı́
projekty. Současně doplnı́ lokálnı́ cestu do classpath projektu. V přı́padě nedosažitelnosti
balı́ku je uživatel informován chybovým hlášenı́m a proces zı́skávánı́ souboru musı́ provést
manuálně.
Tento rys je evidentně překážkou pro vývojáře, kteřı́ nemajı́ přı́stup k Internetu. Vhod může
přijı́t i možnost krátkodobě použı́t jinou verzi některého balı́ku. Maven v tomto směru nesvazuje

1. http://maven.apache.org/

29
 4.3. MAVEN

uživateli ruce, poskytuje možnost nenačı́tat balı́k z archivu, ale použı́t mı́sto něj běžný diskový
soubor specifikovaný cestou. Tato vlastnost je nazvána JAR overriding a zapı́ná se direktivou
maven.jar.override=on v konfiguračnı́m souboru.

4.3.1.3 Plug-iny
Maven je sám o sobě jen malé jádro zajišt’ujı́cı́ základnı́ funkcionalitu. To je obklopeno plug-iny,
které se starajı́ o vykonávánı́ přı́slušných akcı́. Plug-iny jsou skripty enginu Jelly - skripto-
vacı́ho jazyka s XML syntaxı́ interpretujı́cı́ho své skripty na základě Javy a javových kniho-
ven nad použitými elementy. Implicitnı́ sada plug-inů se nacházı́ v adresáři specifikovaném
proměnnou maven.plugin.unpacked.dir (typicky $HOME/.maven/plugins). Maven se
použitı́m této nadstavby stává elegantně rozšı́řitelnou záležitostı́.

4.3.2 Práce s Mavenem

Uživatel pracuje s Mavenem na úrovni přı́kazové řádky či konzolového rozhranı́. Výhodou
konzoly je absence dlouhých prodlev způsobených inicializacı́ Mavenu. V obou přı́padech in-
terakce probı́há pomocı́ přı́kazů odkazujı́cı́ požadovaný cı́l (goal). Seznam všech cı́lů je možné
vypsat přı́kazem maven -g. Každý cı́l je popsán plug-inem. Uživateli, jemuž základnı́ funkci-
onalita nepostačuje, se tedy nabı́zı́, vzhledem ke schopnostem a rozšiřitelnosti Jelly, relativně
široké možnosti.
Jednoduššı́ alternativou definice nových cı́lů v rámci jednoho projektu je využitı́ sou-
boru maven.xml. Primárně sloužı́ k definici implicitnı́ho cı́le použitého při bezparametrickém
spouštěnı́ Mavenu, alternativně může obsahovat definice cı́lů vyjádřené opět pomocı́ Jelly.
Pokud se začı́ná vyvı́jet nový projekt, lze požádat Maven o vytvořenı́ stromové struktury
přı́kazem maven -Dpackage=cely.nazev.noveho.baliku genapp. V aktuálnı́m adresáři se vy-
generuje struktura odpovı́dajı́cı́ názvu balı́ku včetně několika konfiguračnı́ch souborů, mezi
nimiž nechybı́ i project.xml - perzistentnı́ reprezentant POM.
V přı́padě, že uživatel hodlá integrovat Maven do již vyvı́jeného projektu, je nutné vytvořit
přinejmenšı́m soubor project.xml a popsat tak současný stav a rozloženı́ vývojových zdrojů.

4.3.3 POM - Deskriptor projektu

Alfou a omegou mavenového projektu je tedy Project Object Model (POM), jehož popisovač
je reprezentovaný typicky souborem project.xml v kořenovém adresáři projektu. Vytvo-
řenı́ tohoto dokumentu je tudı́ž pro použı́vánı́ Mavenu nezbytné. Následuje popis vybraných
konstrukcı́.

• extend - Mavenovský projekt je schopný dědit svoje vlastnosti po rodičı́ch. Projekt, je-
hož project.xml (resp. ceta k němu, může být relativnı́ i absolutnı́) odpovı́dá hodnotě
v tomto elementu je zdrojem implicitnı́ch vlastnostı́.

• organization - Struktura informujı́cı́ o organizaci, která projekt vyvı́jı́.

• package - Tato hodnota se použije jako jméno balı́ku (package) při generovánı́ Javadocu.

• siteAddress - URL serveru, na kterém bude vystavena webová prezentace projektu.

• siteDirectory - Adresář serveru, ve kterém bude prezentace přı́tomná.

• distributionSite - Server, na kterém bude distribuce vystavena.

• distributionDirectory - Adresář serveru, ve kterém bude prezentace přı́tomná.

30
 4.3. MAVEN

• repository - Jedná se o strukturovaný element, který popisuje přı́stup k archı́vu

(repository), kde je projekt vyvı́jen (CVS, SVN, ...).

• mailingLists - Velice zajı́mavá a u většı́ch projektů neméně užitečná vlastnost, která

odkazuje na mailing listy spojené s projektem.

• developers, contributors - Elementy reprezentujı́cı́ jména autorů projektu.

• dependencies - Tento kontejner elementů dependency specifikuje všechny závislosti

projektu na extenı́ch balı́cı́ch.
Každá ze závislostı́ je popsaná pomocı́ elementu dependency s následujı́cı́ strukturou:

– groupId - jméno skupiny projektů

– artifactId - jméno projektu (balı́ku)
– version - požadovaná verze
– jar - jméno balı́ku, pokud nevyhovuje implicitnı́ tvořené jako artifactId-
version.jar
– type - typ, defaultně jar, jinak také plugin nebo ejb
– url - URL, které je nabı́dnuto uživateli, pokud se balı́k nepovede stáhnout

• build - Jak již bylo řečeno, soubor project.xml popisuje opravdu všechny potřebné
informace o projetu. Zvlášt’ tedy nechybı́ informace o tom, jak projet sestavit. Element
build navı́c specifikuje jak sestavit testovacı́ třı́dy a jak vytvářet výsledný balı́k.

– sourceDirectory - Cesta k adresáři se zdrojovými soubory, která se použije při

sestavovánı́ projektu. Je relativnı́ vzhledem k souboru project.xml.
– sourceModifications - Definuje, které soubory se majı́ ze sestavovánı́ vyřadit,
nebo naopak které je žádoucı́ přidat pokud nebyla načtena některá ze třı́d. Touto
cestou lze poměrně elegantně vyřešit třeba situaci, kdy je projekt sestavován na
offline stroji - sestavovánı́ tak nemusı́ skončit chybovým hlášenı́m o nedostupnosti
balı́ku, můžeme využı́t některé z vlastnı́ch pseudotřı́d.
– unitTestSourceDirectory - Specifikje adresář s třı́dami určenými k testovánı́.
Ty jsou pak testovámy pomocı́ JUnit.
– unitTest - Tento element podrobněji specifikuje, které z testovacı́ch třı́d se majı́
zahrnout do samotné testovacı́ procedury. Mimo to umožňuje dodefinovat zdroje,
jež budou k testovánı́ potřebné.
– resources - Podrobný popis zdrojů, které je potřeba přiložit k výslednému JAR
archı́vu projektu. Tento prvek je výborně aplikovatelný na soubory typu vzorových
šablon, nebo alternativı́ch konfiguračnı́ch souborů.

31
Kapitola 5

Závěr

Problém velkého množstvı́ formátů elektronických dokumentů lze řešit jedině konvergencı́
k striktně definovaným standardům a doporučenı́m. Za základnı́ identifikačnı́ znak kvalitnı́ho
formátu lze potom považovat předevšı́m dostupnost, nadčasovost a jeho snadnou editovatel-
nost. Řešenı́ otázky hledánı́ toho optimálnı́ho nabı́zı́ DocBook.
Jako model postavený na XML disponuje téměř univerzálnı́ čitelnostı́, svou flexibilitou
pokrývá poměrně širokou oblast použitı́. Pozitivem je i to, že plně odstiňuje logickou strukturu
od přı́padné prezentace. Generovat nějakou vizuálnı́ podobu z logické struktury totiž v zásadě
nenı́ problémem, při cestě opačným směrem se ale můžeme setkat s řadou komplikacı́. Tohoto
faktu využı́vá i transformačnı́ model XML, totiž XSL, dalšı́ standardnı́ a silně rozšı́řený koncept.
Jiným kladem modelu značkovaných dokumentů je jejich katalogizovatelnost. Touto cestou
lze vytvářet obrovské stromové struktury, v nichž lze efektivně vyhledávat. Konkrétnı́m přı́-
kladem takovéto aplikace je XML:DB, databáze, jejı́ž elemetárnı́ strukturou jsou namı́sto řádků
či objektů XML dokumenty.
Kvality mnoha formátů zastiňuje jejich neotevřenost, závislost na platformě či aplikaci.
Charakter XML, jakožto nadmnožiny DocBooku, podobné problémy zcela popı́rá.
DocBook je tedy postaven na silé koncepci. Situace ovšem nenı́ úplně černobı́lá, i on se potýká
s některými problémy. Předevšı́m nemůže (alespoň v dohledné době) uspokojit uživatele zvyklé
na přežitky charakteru kancelářských balı́ků, a to i přes několik velmi kvalitnı́ch WYSIWYG
editorů, jež jsou v momentálmě k dispozici. Navı́c lze XML i DocBook považovat za neustále
se vyvı́jejı́cı́ formáty, což přirozeně vede k nestálé čitelnosti (byt’, v přı́padě těchto technologiı́,
minimálnı́) takto uchovávaných dat.
Uživatelé z řad technicky zdatnějšı́ch v DocBooku ovšem nezřı́dka najdou zalı́benı́. Právě
jistá dávka nadhledu je tı́m pravým katalyzátorem pochopenı́ schopnostı́ a možnostı́, které
nabı́zı́ použitı́ kvalitně navrženého značkovánı́.

32
Literatura

[ADLER] Adler, S., Berglund, A., Caruso, J., Deach, S., Graham, T., Grosso, P., Gutentag,
E., Milowski, A., Parnell, S., Richman, J., Zilles, S.: Extensible Stylesheet Language
(XSL) Version 1.0, W3C, 2001, http://www.w3.org/TR/xsl/ .

[CLARK] Clark, J.: XSL Transformations (XSLT) Version 1.0, W3C, 1999, http://www.w3.
org/TR/xslt/ .

[HOLZNER] Holzner, S.: XSLT: přı́ručka internetového vývojáře, Computer Press, 2002, 8-07226-
600-4.

[KAY] H. Kay, M.: Saxon: Anatomy of an XSLT processor, IBM, 2001, http://www-106.
ibm.com/developerworks/library/x-xslt2/ .

[WALSH] Walsh, N., Muellner, L.: DocBook: The Definitive Guide, O’Reilly, 1999, 1-56592-
580-7.

33